Notifications of login attempts from Sonos
The problem
I’m getting an “invalid authentication” notification in Home Assistant multiple times a day triggered by my Sonos device. Happens so often that HA bans the IP of my Sonos.
It may be linked to after playing a media file located in the media folder of HA. The in the logs always has and error with a link to a "Requested URL" that is a file in the media folder.
I don't now why it would even attempt a login to HA, or why it is flagged in this manner.
Deleting and re-installing the integration changes nothing. Re-setting/rebooting the Sonos also does nothing.
What version of Home Assistant Core has the issue?
2023.2.5
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Sonos
Link to integration documentation on our website
https://www.home-assistant.io/integrations/sonos
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Logger: homeassistant.components.http.ban
Source: components/http/ban.py:82
Integration: HTTP ([documentation](https://www.home-assistant.io/integrations/http), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+http%22))
First occurred: 8:16:55 AM (3 occurrences)
Last logged: 9:00:32 AM
Login attempt or request with invalid authentication from 192.168.1.68 (192.168.1.68). Requested URL: '/media/local/Door%20Whistle.mp3?authSig=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI0NjFjOTMzNTQ5Mjk0MGYzODRmNGViODRjMTRkMjM3MSIsInBhdGgiOiIvbWVkaWEvbG9jYWwvRG9nIFdoaXN0bGUubXAzIiwicGFyYW1zIjp7fSwiaWF0IjoxNjc2ODU4MDQxLCJleHAiOjE2NzY5NDQ0NDF9.xGXENxpjVwfbgLV3EgqEUQMIVWiBmmBoHor7w9ciPEU'. (Linux UPnP/1.0 Sonos/71.1-38080 (ZPS15))
Additional information
No response
Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (http) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of http can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign httpRemoves the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
http documentation http source (message by IssueLinks)
Hey there @cgtobi, @jjlawren, mind taking a look at this issue as it has been labeled with an integration (sonos) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of sonos can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign sonosRemoves the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
sonos documentation sonos source (message by IssueLinks)
When you play media from Home Assistant, it attaches authentication to the URL (the ?authSig part) which is only valid for 1 day (as set by async_process_play_media_url). It looks like Sonos is trying to fetch this URL again at a later point, causing it to trigger the invalid authentication.
Hey there @hunterjm, mind taking a look at this issue as it has been labeled with an integration (media_source) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of media_source can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign media_sourceRemoves the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
media_source documentation media_source source (message by IssueLinks)
I agree that is what it looks like, but why is it trying to fetch the file again at some random time?
Perhaps it's the only/first item in the Sonos device's playqueue. If it tries to play without new media chosen it will try to resume from its local playqueue.
Hi, I am having exactly the same problem. Do you have any suggestions on how to resolve please.
I may have found a solution to this issue.
All my media sound files that play through my Sonos I renamed to remove spaces, and replaced with an underscore or hyphen. Since having done this, no more login errors I’ve encountered. Fingers crossed that the spaces was causing the issues.
I am getting these errors as well. I am only using one file that does not contain any spaces.
Logger: homeassistant.components.http.ban Source: components/http/ban.py:82 Integration: HTTP (documentation, issues) First occurred: 24 April 2023 at 08:41:47 (14 occurrences) Last logged: 06:27:29
Login attempt or request with invalid authentication from SonosZP (192.168.1.225). Requested URL: '/media/local/doorbell.mp3?authSig=key'. (Linux UPnP/1.0 Sonos/72.2-40060 (ZPS18)) Login attempt or request with invalid authentication from 192.168.1.106 (192.168.1.106). Requested URL: '/media/local/doorbell.mp3?authSig=key'. (Linux UPnP/1.0 Sonos/72.2-40060 (ZPS19)) Login attempt or request with invalid authentication from 192.168.1.225 (192.168.1.225). Requested URL: '/media/local/doorbell.mp3?authSig=key'. (Linux UPnP/1.0 Sonos/72.2-40060 (ZPS18))
+1
When you play media from Home Assistant, it attaches authentication to the URL (the
?authSigpart) which is only valid for 1 day (as set byasync_process_play_media_url). It looks like Sonos is trying to fetch this URL again at a later point, causing it to trigger the invalid authentication.
Pretty sure this is the reason. Once sonos is ip banned, I can't stream media anymore. Can be annoying when you use it for the doorbell. 😃
My 2 cents on this issue... I'm getting the same error on HA:
Logger: homeassistant.components.http.ban Source: components/http/ban.py:82 Integration: HTTP (documentation, issues) First occurred: 12:07:26 (2 occurrences) Last logged: 12:23:53
Login attempt or request with invalid authentication from Sonos-542A1BD5E58E.fritz.box (192.168.178.45). Requested URL: '/media/local/Seatbelt.mp3?authSig=eyJhbGci [...] Ys0uvKI'. (Linux UPnP/1.0 Sonos/74.0-43110 (ZPS31))
It seems I get this error as soon I restart the integration too.. I than tried to set the Sonos device IP into the "trusted_networks" auth providers only to discover they are ignored for http auth as explained https://github.com/home-assistant/core/issues/37029 Moreover, as per my understanding, pull request https://github.com/home-assistant/core/pull/75870 is only related to camera device..
So, no option other than disable ip_ban (that is bad) until a fix is available...
Same issue here, of course, but only on specific speakers, only those that played a media file. TTS doesn't seem to use that failing AuthSig parameter. So here's a (stupid) workaround: run a Piper TTS script (saying nothing) after playing a media file. Works like a charm so far ...
Just come to say i've come across this now, as i'm using dorrbell.mp3 on my Sonos speakers. Strangely tho i have 4 speakers that play it, and only one will get banned, then after a few more days or it working/playing fine another one will get banned.
I occasionally encounter this error as well. Manually playing the media file in the browser across all my Sonos devices seems to resolve the issue for an extended period.
Seems many people are still having this issue. So, can there be a fix where the the Sonos authorization code expires and it is forced to get it reissued, avoiding the Sonos device using stale credentials?
I'm 99% sure this is caused by:
- Local media hosted by HA is played on a Sonos device. This is passed as a URL with a temporary auth token attached.
- That media plays and is left in the Sonos queue (check in your Sonos app).
- Some time later an action causes the Sonos device to play from its queue and it attempts to re-play the media from HA, but the token is no longer valid.
A workaround is to clear your Sonos queue to remove the item(s). Alternatively, the announce option should avoid placing the media into the queue. See the Sonos integration docs for details on that feature.
A workaround is to clear your Sonos queue to remove the item(s). Alternatively, the
announceoption should avoid placing the media into the queue. See the Sonos integration docs for details on that feature.
Thank you for this!! The announce parameter solved all my doorbell issues. Music also resumes playing after the doorbell sound.
Looking for the root cause, I noticed the login attempts were coming up randomly but always at the same time a new firmware was detected by the soundbar. I then tried disabling automatic updates. No more errors (it's 5 months now) As proof, when a new firmware is available and I start the update manually.. guess what? login attempts come up again during the process. Not sure it's the only cause but someone else maybe can reproduce and confirm my experience.
Yeah, been there.
I'm 120% sure it's stale credentials and it happens when you restart or power cycle either HA or the Sonos in question.
And only if the last thing your Sonos did before the event was playing a local sound file.
Like I said, I've installed Piper, and I'm using a blueprint now to play sound files, which is now followed by Piper saying nothing (blank string) afterwards.
I never saw the issue again, after months and countless restarts and power cycles.
For me the mentioned workarounds here do not work. I used to have this warning a lot, then removed playing all sounds/announcements from HA on my Sonos speakers, completely deleted the integration from HA, then even resetted the 2 Sonos speakers I have and set them up from scratch. Then it was quiet for a long time since early 2023. Then last month it re-appeared again, believe with some HA 2023.11 release. There is no queue in my Sonos app and I never play media from HA to Sonos. In the meantime I only use the integration to have an automation that every night resets the volume to a certain level (so when I turned up the volume last evening to 80% that it sets it in the morning to 20% again). I now tried playing something from HA to see if after the error disappears for maybe at least 1 day. But it does not. As soon as I stream something from my iPhone to the Sonos speaker via Airplay, start, stop the music or whatsoever it throws this warning in HA. Even setting ip_ban_enabled to false for the http configuration does not prevent this warning to show up. It is really annoying.
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 has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
I am still experiencing this issue having the latest update (HA 2024.3.1), so definitely not resolved yet.
This is still an issue for me. Running the latest updates: Core 2024.3.1 Supervisor 2024.03.0 Operating System 12.1 Frontend 20240307.0
Same here, I'm playing media from my synology nas to my Sonos speaker. Token is then passed in the url. Even after stopping media, pausing or clearing queue, the token is still visible in the state of the media player. This causes after a while the login errors and then after a while a ban.
We use these automation for business purposes so it is really annoying, we tried the tts workaround. Will post the result later on. But it would be great if a real fix could be applied to the integration.
Thank you
Same issue here. Core- 2024.4.2 Supervisor - 2024.04.0 Operating System - 12.2 Frontend - 20240404.1
I started seeing this error recently. I added Chime TTS to some of my automations, but I didn't see the warnings until last week, despite Chime TTS being used for a while.
This happens on two of my Speakers: A Sonos Move Gen 1 and a Sonos Play:3. It doesn't happen on a Play:5 and a Sonos One. The Play:5 often plays music, so it usually has a music queue paused. The Sonos One does not have music in its queue most of the time (like the Play:3 and the Move Gen 1) so I don't know why this one doesn't generate the alert.
The automation is using the Sonos Cloud integration to play the mp3 file that shows up in the alert (a Chime TTS generated file). It's targetting the four entities of Sonos Cloud belonging to each speaker.
I tried the workaround of playing an empty TTS Cloud say after, but this hasn't fixed it for me.
Core- 2024.4.2
Sonos Cloud integration
what is this?
My understand of the issue
- it is caused by playing media from an HA directory (this is where TTS mp3 are)
- it is caused by the token expiring and the media still being in the Sonos queue
Solutions
- use the announce parameter to play these items
- Or move the sound files out of the HA directory into a non HA directory.
Deactivating IP ban solved it kind of for me, but hoping that this gets fixed. Still get a IP error every now and then from the devices.
Thanks for looking at this.
My understand of the issue
- it is caused by playing media from an HA directory (this is where TTS mp3 are)
- it is caused by the token expiring and the media still being in the Sonos queue
Solutions
- use the announce parameter to play these items
I'm playing an mp3 file. I've just tested adding the announce parameter and still get the error.
- Or move the sound files out of the HA directory into a non HA directory.
I created a network media share on my NAS and tried to play the media file from there. I still get the error.