[FR] Support `!secret` in YAML

[PaulSD]

From #159 (comment)

2. Is it possible to make this scenario

variables:
  xxx: !secret my_super_secret

supported?

[PaulSD]

We can use secrets in lovelace yaml like:

type: history-graph
hours_to_show: !secret xxxxxx

so I thought may be it could be possible to use them inside variables.

I'm not able to reproduce this ... Your history-graph example gives me:

Configuration error
Error in parsing YAML: unknown tag !<!secret> (line: 2, column: 37)

Am I missing something?

[ildar170975]

Thanks for creating this FR!

I'm not able to reproduce this

Are you trying to use secrets in a storage-mode dashboards?
Secrets only work in yaml files.
Try a yaml-mode dashboard.

---

Some information:
Secrets are usually used as "secrets", i.e. to HIDE data when posting configs in github or sharing then in forums.
A more real-life example could be for a pincode in a custom restriction card:

type: custom:restriction-card
restrictions:
  pin:
    code: !secret my_super_secret_pincode
    text: Enter pin to unlock
card:
  ...

since a pincode could be really important.

But in many cases !secret is used for ANY data which are shared in many yaml-files in config:
-- complex structures like "common settings for input_number entity", "common settings for some card",
-- or simple data like "value of particular option".
Yes, these data are not "secrets" in fact & supposed to be imported via !include like:

type: history-graph
hours_to_show: !include /config/shared/.../common_hours_to_show.yaml

But in this case each entry (even just a simple string) should be a separate yaml-file.
That is why some people import these shared pieces with !secret - and all these pieces can be stored in one secrets.yaml file (could be stored as a separate secrets.yaml in the same folder where a particular package is stored, not in a one global secrets.yaml).
I myself prefer !include method (although it is more cumbersome - but more "correct") & use !secret only for real "secrets".

[PaulSD]

!secret does seem to work for yaml-mode dashboards:

secret.yaml

some_password: $!welcome

configuration.yaml

lovelace:
  dashboards:
    test-dash:
      mode: yaml
      filename: test-dash.yaml
      title: Test
      show_in_sidebar: true

test-dash.yaml

views:
  - title: Test
    cards:
      - type: custom:config-template-card
        staticVariables:
          spw: !secret some_password
        variables:
          vpw: !secret some_password
        card:
          type: vertical-stack
          cards:
            - type: markdown
              content: "${spw} ${vpw} "
            - type: markdown
              content: !secret some_password

Note that !secret does not alter the parsing behavior of CTC (the secret values are substituted into the YAML before CTC parses it, and CTC is unaware of the substitution), so some potentially unintuitive behavior of CTC is relevant here. Specifically:

some_password: $!welcome behaves the same for both the variable substitutions and the content substitution, as the $! disables template evaluation in both cases.

Replacing some_password: $!welcome with some_password: welcome works for the content substitution (because the content substitution isn't evaluated unless it uses ${}), but for the variable substitutions (which are evaluated even if ${} is not used) it results in welcome being evaluated as Javascript, which is invalid and causes an error.

Replacing some_password: $!welcome with same_password: "'welcome'" works for the variable substitutions (the outer quotes are stripped during YAML parsing and 'welcome' is evaluated as Javascript, which is valid and results in the variable being set to the string welcome), but for the content substitution it results in 'welcome' with single quotes, which is probably not what you want.

[ildar170975]

Thanks for an investigation!
But thanks to your efforts with adding a config variable, it became possible to use secrets:

type: custom:config-template-card
entities:
  - sun.sun
variables:
  VAR: config.secret_option
card:
  type: entities
  entities:
    - entity: sun.sun
      name: ${VAR}
secret_option: !secret some_super_secret

where secret_option could have ANY name.