Iframe won't accept/see !secret

Configuration
1

Hi,

using an iframe card to embed windy cards, like this:

  - type: iframe
    title: Rain
    aspect_ratio: 100%
    url: >
      https://embed.windy.com/embed2.html?lat=lat&lon=lon
      &zoom=5&level=surface&overlay=rain&menu=&message=true&marker=&calendar=
      &pressure=&type=map&location=coordinates&detail=true&detailLat=lat&detailLon=lon
      &metricWind=default&metricTemp=default&radarRange=-1

shows fine. Since these urls contain the lat/lon, I’d like to move the full url to secrets.yaml and simply config like:

  - type: iframe
    title: Rain
    aspect_ratio: 100%
    url: !secret windy_rain

which errors out saying 54 which of course it is…

2

how are you defining it in your secrets?

3

tried various options, lastly:

windy_rain: >
  https://embed.windy.com/embed2.html?lat=lat&lon=lon
  &zoom=5&level=surface&overlay=rain&menu=&message=true&marker=&calendar=
  &pressure=&type=map&location=coordinates&detail=true&detailLat=lat&detailLon=lon
  &metricWind=default&metricTemp=default&radarRange=-1

tried it with all on 1 line also, didn’t work

4

quotes should work oneline or not.

windy_rain: "https://embed.windy.com/embed2.html?lat=lat&lon=lon
  &zoom=5&level=surface&overlay=rain&menu=&message=true&marker=&calendar=
  &pressure=&type=map&location=coordinates&detail=true&detailLat=lat&detailLon=lon
  &metricWind=default&metricTemp=default&radarRange=-1"
5

will try, thanks.
its just that this works fine

bing_locatie_name: >
  https://dev.virtualearth.net/REST/v1/Imagery/Map/Road/
  {{ state_attr('device_tracker.life360_name','latitude') }},
  {{ state_attr('device_tracker.life360_name','longitude') }}/14?mapSize=500,500&pp=
  {{ state_attr('device_tracker.life360_name','latitude') }},
  {{ state_attr('device_tracker.life360_name','longitude') }};54;
  &key=longkey

for a camera image

6

well what do you know.
Had another issue with the !secret for the dark sky sensors, also newly added to secrets file. Rendered the same issue while all other (older ones) where loading fine.

Gave it a hard refresh/cache clear in the browser (not the three dots top left refresh) et voila, the Darksky sensor is live and the 3 windy iframes I had configured.

Don’t really understand that because the secrets have nothing to do with page refreshing do they? all backend in this case I would have thought.

so, more than 1 way to use the longer lines in secrets.
1 thing to take into account with these urls is the & sign should not end the line, but start a new line. Otherwise the url is broken, no matter the multiline notation or quotes

7

Not sure, it’s possible that lovelace will refresh the secrets file. I haven’t dug that far into it.

8

In my case I am using “window.location.hostname” to resolve host from the client browser in order to have it working with internal and external HA url. The only thing is, I do not know how to use secret in my case.

Here is my code but it is not working, it is complaining about Unexpected token ‘!’.
Workaround is to use config-template-card and “states[‘input_select.password’].state” but I would like to use secret everywhere if possible.

type: custom:config-template-card
entities:
  - input_select.password
card:
  type: iframe
  style: |
    #root {
      height: calc(100vh - 48.5px);
      padding-top: 0 !important;
    }
  url: >-
    ${'http://'+window.location.hostname+':20530/sysmanager.php?username=amilino&password='+secret! password}

This is alternative that works, but not what I want in the end.

  url: >-
    ${'http://'+window.location.hostname+':20530/sysmanager.php?username=amilino&password='+states['input_select.password'].state}
9

Ever found a solution to this secret conundrum?

10

I used input.select on the iframe page:

url: >-
    ${'http://'+window.location.hostname+':20530/sysmanager.php?username=amilino&password='+states['input_select.1nuc_root_password'].state}

and input select configuration:

1nuc_root_password:
  name: Password
  options:
    - !secret 1nuc_root_password
  icon: mdi:account-key
11

@alanmilinovic, doesn’t the log show the input_text password when it’s changed (even if the input_text is masked as a password which itself kind of a bug), and also the password is stored in the database.

Perhaps the low bar is not allow administrative actions for whatever the iframe is pointing too with the password in use if that particular dashboard is for general use. One can always restrict the dashboard to Admin if the iframe target is sensitive.

The way HA deals with passwords is not too secure. Definitely good to have full disk encryption and encrypt backups that are stored elsewhere.

For URL’s that need user management aside from dashboard control might be better to have a script or service that maps HA users to URL’s with hashed passwords and/or OAuth.

12

Yes, one can see the value of input_text in history. At the moment I am the only one that is using HA and HA has authentication so it is secured enough for me.

If one day HA introduce RBAC and I will share it with some friends or family members, then I will have to think about some other solution for sure. I am hoping that it will be possible in the future to restrict access to History and Developer tools inside HA.

13

There are a few things I found that help with using input_text, etc to frame a URL.

If a user is not an administrator, they don’t get the developer tools in the side panel.
If you set both the recorder (history) and the logbook off for an entity, it does not appear in the logbook. There is a long standing bug/design flaw so both have to be set off for the entity.

recorder:
  exclude:
    entities:
      - input_text.a_password

logbook:
  exclude:
    entities:
      - input_text.a_password

There may be other risks and of course state is still stored in the database but at least this is something.

1 Like
14

I already did that and then I realized that it is staying in state for the entity, but yea it is something. The best solution would be to use secrets directly in cards but unfortunately that is not possible and not sure if it would technically even be feasible.

15

Secrets are supported in lovelace - but only for yaml-mode dashboards:
– you cannot use a secret in “yaml editor” of a card of a storage-mode dashboard;
– you cannot use a secret in “raw yaml configuration” of a storage-mode dashboard;
– you can use a secret in a yaml file of a yaml-mode dashboard (and you can edit your “secrets.yaml” file and then reload a dashboard to see changes).

16

I am using ui lovelace yaml mode when editing cards, so it will not work for me.