Frontend: any `picture-entity` cards that are backed by the `camera_proxy` loose their auth token/authSig and display a grey `image-broken.svg` thumbnail when HA is restarted.

Created on 2 Dec 2019  路  10Comments  路  Source: home-assistant/frontend

Checklist:

  • [X] I updated to the latest version available
  • [X] I cleared the cache of my browser

Home Assistant release with the issue:

I am running inside docker on Ubuntu. I am fetching the latest tag. Specifically, versions:

Home Assistant 0.102.2
Frontend version: 20191119.6 - latest 

But, this issue has been present in versions going as far back as .6 or as long as i've been using the camera_proxy

Last working Home Assistant release (if known):
I have never had a release of HA w/o this issue.

UI (States or Lovelace UI?):

I am using Lovelace UI

Browser and Operating System:

I experience this issue on every browser worth using: chrome, and firefox. I have tested this across mostly OSX based devices, but also a few android, iOS and chromeos devices. I am confident that the browser does not matter as the flaw is probably in the client-side lovelace JS code... specifically the code that updates the various DOM objects once the connection to HA has been re-established.

Description of problem:

Here's a (simplified) way to reproduce:

  1. Create a device w/ this configuration:
  - platform: generic
    name: Camera01
    # I didn't do my homework before buying and just assumed that because there was OK integration between HA and Unifi NVR,
    #   the unifi cameras would be easy to integrate when they're operated off of unifi protect. 
    # Turns out, i was 100% wrong. Lesson learned! Never buying Ubiquity for anything other than wifi ever again.
    # In any event, we can still get a feed from the camera to show up in the UI by tapping into the 
    #   anonymous snapshot preview. This must be turned on in the controller for the camera first!
    ##
    still_image_url: https://${Camera_IPv4}/snap.jpeg
    stream_source: rtsp://${NVR_IPv4}7447/${Some_Authenticated_UUID}
    # Camera will issue self-signed cert
    verify_ssl: false

See here for the thread that suggests using the raw feed + the proxy.

  1. Add a simple picture entity to your LoveLace:
      - type: vertical-stack
        # See: https://www.home-assistant.io/lovelace/vertical-stack/
        # Title can be obtrusive...
        #title: Camera01_Subject
        cards:
          - type: picture-entity
            entity: camera.camera01
  1. Load up the UI. Assuming that the stream source is valid (in the case of Unifi Protect, the Some_Authenticated_UUID is a very specific token that will entitle you to the stream; I used VLC to confirm that the feed worked before introducing it to Home Assitant.

You will see a static image that will refresh every several seconds. Tapping on the image/card will launch a "bigger" feed that is more or less live.

So far, everything's working _exactly_ as you'd expect.

  1. Stop and then re-start the HA container/server. do not close the web UI. Once HA has been stopped / while it's booting back up, Lovelace will display a "Connection lost... waiting for connection...." message in the bottom left.

  2. When the UI has re-connected, the connection lost... message will go away and the UI will refresh with current values. however the static image for each picture-entity will be replaced with a grey "image broken" image. Tapping on the card will still launch the "live" stream as expected.

I have included two screenshots from FireFox on android, but the exact same behavior happens on Chrome / Firefox on OSX, LInux, and Windows systems... and iOS devices.

When the UI is loaded, i see the thumbnail as expected:
https://imgur.com/ZqQKw4A

And after restarting HA, but not refreshing the UI i see a grey bar:

https://imgur.com/OadEtMn

Javascript errors shown in the web inspector (if applicable):

I don't see any errors in the console, but the URL that the image is fetched from does change:

When things are working, i see a new network request to this endpoint every few seconds; the interval between requests directly matches the interval between thumbnail refreshes.

http://${HA_FQDN}:8123/api/camera_proxy/camera.camera01?authSig=${240_characters_that_look_b64_encoded}

And after the HA restart, the lovelace UI is able to re-connect to the server and then the network console shows two requests in rapid succession:

http://${HA_FQDN}:8123/static/images/image-broken.svg
http://${HA_FQDN}:8123/lovelace/undefined

Additional information:

I am not a front end developer; the last time i did any front-end work, IE6 was still a thing and j-query was the hotness. I am a bit embarrassed to admit that i don't really know how to use the JS debugger built into modern browsers now, so i'm not 100% sure what other info i can provide. Through elimination and deduction, i am super confident that the issue does not depend on the client's host OS or browser as this issue has been on my "document and file" list for at least 6 months. SO i am confident that it's in seldom-used/tested HA code and, because the host OSs/Devices have changed, but the issue stays the same, i am confident that the issue is almost certainly in the code that's executed when Lovelace re-gains its connection to the back end.

I did notice that the div that the snapshot is rendered in does have some attribute that's set to the 240_characters_that_look_b64_encoded. This div seems to be cleared of properties/attributes once the connection to HA backend has been re-established. There's a property of the div w/ the valueundefined... same as what's seen in the web requests following UI re-connection.

This issue does not seem to come up when the connection between the client and HA backend is severed, but HA is not restarted.

I don't know _where_ the authSig comes from, but i'd bet that this whole bug report can be summed up as "lovelace fails to renew any authSig token for camera_proxy calls after HA is restarted and connection to API is re-established"

Please let me know if there's any additional info that'll help get this looked at or triaged. If somebody can point me to the JS that is run when the UI re-establishes its connection to the API, i may be able to do some more digging...

I can immediately get rid of the grey bars by refreshing the UI via my browser's controls. Because the "work around" has been so trivial, i haven't opened a bug... however, i am now starting to deploy LoveLace on - effectively - kiosks w/ no user control over the URL or ability to refresh the page w/o restarting the entire device... so now, suddenly, it's a usability issue. If i deploy a new HA config that requires restart, the UI on all kiosk instances will be broken until they can be physically restarted.

bug

Most helpful comment

This issue has not been resolved. As of HA version Home Assistant 0.106.2 is is still present.

All 10 comments

I have some problem with generic cam and lovelace cam view. When i try see stream over web interface(lovelace) web interface will not working. but log no have error. Container is startup. But web not show. I use last hassio 0.102.3 in doker debian. problem after update to last version

rollback to 0.101.3 and all cam view work normally.

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 馃憤
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

This issue has not been resolved. As of HA version Home Assistant 0.106.2 is is still present.

Same issue here with version 0.106.5, also get an "Unauthorized login" notification.

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 馃憤
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Yes, this is _still_ an issue on the new 0.111 release.

On a related note to what @mike9011 said above:

Same issue here with version 0.106.5, also get an "Unauthorized login" notification.

I too see the 'unauthorized' notifications from most clients on my LAN and sometimes will see the IP of the client i have configured for autologin end up in the ip_bans.yml file...

I suspect that the root of the cause is somewhere in the image proxy component not checking the auth the same way other components do, but this is pure speculation on my part!

I too see the 'unauthorized' notifications from most clients on my LAN and sometimes will see the IP of the client i have configured for autologin end up in the ip_bans.yml file...

I suspect that the root of the cause is somewhere in the image proxy component not checking the auth the same way other components do, but this is pure speculation on my part!

After some extensive testing, i've managed to solve the issue behind the client showing up in ip_bans.yml periodically. The picture_entity card issue is still present, though :(.

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 馃憤
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

This is not yet resolved.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bmf7777 picture bmf7777  路  3Comments

TheZoker picture TheZoker  路  3Comments

SeanPM5 picture SeanPM5  路  4Comments

GauthamVarmaK picture GauthamVarmaK  路  3Comments

andriej picture andriej  路  3Comments