Notifications of login attempts from Sonos

[rtorchia]

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

[home-assistant[bot]]

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 close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign http` Removes 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)}}

[home-assistant[bot]]

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 close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign sonos` Removes 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)}}

[balloob]

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.

[home-assistant[bot]]

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 close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign media_source` Removes 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)}}

[rtorchia]

I agree that is what it looks like, but why is it trying to fetch the file again at some random time?

[jjlawren]

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.

[LidoCosta]

Hi, I am having exactly the same problem. Do you have any suggestions on how to resolve please.

[rtorchia]

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.

[201505409]

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))

[rvdp]

+1

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.

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. 😃

[mbuico]

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...

[OlwinFroon]

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 ...

[cooljimy84]

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.

[koenraadhaedens]

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.

[rtorchia]

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?

[jjlawren]

I'm 99% sure this is caused by:

1. Local media hosted by HA is played on a Sonos device. This is passed as a URL with a temporary auth token attached.
2. That media plays and is left in the Sonos queue (check in your Sonos app).
3. 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.

[rvdp]

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.

Thank you for this!! The announce parameter solved all my doorbell issues. Music also resumes playing after the doorbell sound.

[mbuico]

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.

[OlwinFroon]

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.

[stef-g]

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.

[issue-triage-workflows[bot]]

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.

[Didel]

I am still experiencing this issue having the latest update (HA 2024.3.1), so definitely not resolved yet.

[smithnb]

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

[EscapeRush]

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

[SirCadian]

Same issue here. Core- 2024.4.2 Supervisor - 2024.04.0 Operating System - 12.2 Frontend - 20240404.1

[motoridersd]

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

[PeteRager]

Sonos Cloud integration

what is this?

[PeteRager]

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.

[andyfrei]

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.

[SirCadian]

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.

[PeteRager]

@SirCadian did you power cycle the Sonos speakers before the test?

[SirCadian]

I hadn't but I have now. Some weird behaviour. Here's the code:

alias: Test File
sequence:
  - service: media_player.play_media
    data:
      media_content_type: audio/mpeg
      media_content_id: media-source://media_source/local/SoundClips/Service_Bell2.mp3
      announce: true
    target:
      device_id: xxx
mode: single

Despite what it says, the media source isn't local, it's in a network share on my NAS mounted through Home Assistant network storage. I set up the share, copied the file in, put together a script (code above) and restarted both HA and the Sonos device.

If I change the device_id to be the google speaker in my study, everything works fine and the bell plays. If I change it to be the Sonos speaker in the kitchen, no sound plays and the login error message shows. If the file is local, rather than on the remote network share, then the file will play and I get the error. Both ways I get the login error.

[PeteRager]

Since you are serving the media file from HA, that's where Sonos comes to get it.

If you can access it from the NAS. E.g. http://mynasipaddress/music/Soundclips/.....

Then pass that url in and Sonos will play it directly from the NAS. Test the URL in the web browser.

what is the exact error you are getting in the log?

[PeteRager]

It's also possible that after several attempts the Sonos gets added to the ip ban list. Look at the docs here https://www.home-assistant.io/integrations/http/

[SirCadian]

Since you are serving the media file from HA, that's where Sonos comes to get it. If you can access it from the NAS. E.g. http://mynasipaddress/music/Soundclips/..... Then pass that url in and Sonos will play it directly from the NAS. Test the URL in the web browser.

My NAS doesn't serve up over http like that, it uses SMB, so I ran up a quick Apache server in docker and served the file over that. I still got the error.

what is the exact error you are getting in the log?

Error is as follows.

Login attempt or request with invalid authentication from x.x.x.x (x.x.x.x). Requested URL: '/media/local/Explorers.mp3?authSig=xxxx'. (Linux UPnP/1.0 Sonos/78.1-52020 (ZPS15))

The interesting thing is that this is not the file I'm trying to play and not the speaker I'm trying to play it on. I'm trying to play Service_Bell.mp3 on the Kitchen Sonos. The failed login is from my Sonos Connect in the Lounge and it's trying to play a different MP3 file that's on a once-a-week time based trigger and I've never tried to play the file from that device, the code has only ever addressed the Kitchen Sonos device.

It looks as though, at some point in the past, somehow the Sonos Connect got asked to play Explorers.mp3. Maybe this was because it was part of the playing group at the time or some weird interaction with Sonos Snapshot/Restore (I used to use Snapshot, Play Media, Restore before I found out about announce thanks to your post above). From there on out, for some reason, it has tried to resume playing that file whenever I use Play Media to try and play any file on another device. Again, not sure why that would be the case.

The solution was as follows:

• Set 'announce:true' for both Explorers and Service_Bell announcements.
• Clear the playlist on the Sonos Connect (I wrote a short script to do this and ran it).
• Play some music on the Sonos Connect to change the currently playing media item.
• Reboot Home Assistant.
• Reboot Sonos.

I'm finally error free. Hope this helps someone with similar issues. Thanks for the help, Pete.

[PeteRager]

If you have a public SMB share (e,g, no authentication required), you can access it using this url syntax

x-file-cifs://HOSTNAME/sharename/artist/album/01%20-%20Song.mp3

[PeteRager]

The situation could be circular. Here's my understanding of the circle:

1. media player in HA want to show album artwork
2. The Sonos integration is asked for the artwork
3. The integration calls an endpoint on the speaker requesting artwork
4. The speaker tries to load artwork from the HA url.
5. HA blocks the request because the token is too old.

Newer speakers may cache the image in step 4, which may be why this doesn't happen on all speakers.

Using the Sonos app directly will cause similar thing to happen - except the app goes directly to the speaker.

It may be that playing on any speaker forces creates a data update, the retriggers this cycle.

[SirCadian]

If you have a public SMB share (e,g, no authentication required), you can access it using this url syntax x-file-cifs://HOSTNAME/sharename/artist/album/01%20-%20Song.mp3

I run private shares that require authentication, but still useful to know, thanks.

It may be that playing on any speaker forces creates a data update, the retriggers this cycle.

I've not seen the issue re-occur yet. I'll post here if it raises its head again.

[mwolter805]

Started having this issue after updating my Sonos Beam 2 a few days ago. No longer could local media in the media viewer (/media) be played via an automation service call.

This was the error log received

Logger: homeassistant.components.http.ban  
Source: components/http/ban.py:138  
integration: HTTP ([documentation](https://www.home-assistant.io/integrations/http), [issues](https://github.com/home-assistant/core/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+http%22))   
First occurred: 2:56:37 AM (62 occurrences)   
Last logged: 3:44:13 AM

Login attempt or request with invalid authentication from <IP> (<IP>). Requested URL: '/media/local/Large%20Waterfall%20deep.mp3'. (Linux UPnP/1.0 Sonos/78.1-52020 (ZPS31))

Found two things that needed to be changed.

1. /media needed to be added to allowlist_external_dirs

   homeassistant:
   allowlist_external_dirs:
   - /media

2. The scheme (http), domain and port needed to be removed from the service media_content_id: key

This did not work

- service: media_player.play_media
data:
media_content_id: >-
http://homeassistant.<DOMAIN>:8123/media/local/Large%20Waterfall%20deep.mp3
media_content_type: music
enqueue: play
target:
device_id: 51845c2fc51d8a7a5c540bb3bb19d734

This worked

- service: media_player.play_media
  data:
    media_content_id: >-
      /media/local/Large%20Waterfall%20deep.mp3
    media_content_type: music
    enqueue: play
  target:
    device_id: 51845c2fc51d8a7a5c540bb3bb19d734

I also removed the Sonos integration and reconnected it to the speaker. Not sure if this helped but it might have been necessary.

This issue had me troubleshooting it for a few hours. Hope this info saves someone some time.

[PeteRager]

@mwolter805 what version of ha?

[mwolter805]

@PeteRager The issue started on 2024.4.4 and was also present on the latest (2024.5.2). Installation is the container version.

[PeteRager]

I

@PeteRager The issue started on 2024.4.4 and was also present on the latest (2024.5.2). Installation is the container version.

Is the container in host mode or bridged?

[mwolter805]

@PeteRager MACVLAN and no ports are blocked (no firewall). So pretty close to host mode. HA container is on the same subnet as the Sonos. No firewall or router between HA and the Sonos.

[irowan]

@PeteRager The issue started on 2024.4.4 and was also present on the latest (2024.5.2). Installation is the container version.

Same here. 2024.5.4

[timiman]

Same here w/ 2024.5.4 and one of my 3 Sonos Roam. I have cleared playlist, play an empty file with tts, rebooted specific Sonos device etc. Still getting those notifications every some dozen of seconds. I have to mention that I'm using SonosTalk app -had no problems for months. And also all sounds, announcements, media etc are being played just fine through the specific Sonos speaker which creates these illegal login notifications.

[timiman]

Just now, I've played a mp3 file on the Sonos device from HA UI, which file was on HA's media folder and the notifications stopped after playback ended! I do not know what triggered to whole think to stop the illegal logins -or what made them start. Hope its gone for good.

[gerdesj]

Thank you everyone hereabouts. This was starting to get on my nerves! I use the nginx proxy add on to do Lets Encrypt SSL etc and that was logging a 403 error. I tried setting my advertised internal address to http://w.x.y.z:8123 and that failed too. My external access is mediated via a HA Proxy on my pfSense router, so ip_ban is not needed in my case.

So, I now have this stanza in my configuration.yaml and my Sonos speakers now work:

# Disable ip_ban to stop Sonos getting blacklisted - JG 28 May 2024
http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.30.33.0/24
  ip_ban_enabled: false

If you don't use a proxy, you will only really need the line: _ip_banenabled: false under http:. The other lines refer to using a proxy. Even so, having those extra lines will not hurt. The x_forwarded line refers to a header that a proxy might insert and it will help with logging and the trusted_proxy thing means a Docker based proxy will work.

Note that ip_ban is normally a good thing to have enabled. It is a simple component of an application firewall - part of any decent "defence in depth" approach to exposing your stuff to the internet. You won't destroy your HA's security by turning this feature off, so do it if it gets your functionality back.

[iCSpotRun]

Not sure if this helps narrow the issue down, but I started getting this error only after creating an automation to play media stored in the My Media location. Announce flag is True. Here is the log - I replaced the signature with 'XYZ' for easier reading.

Logger: homeassistant.components.http.ban
Source: components/http/ban.py:135
integration: HTTP (documentation, issues)
First occurred: June 19, 2024 at 5:50:29 PM (112 occurrences)
Last logged: 6:48:39 AM

Login attempt or request with invalid authentication from 10.10.100.171 (10.10.100.171). Requested URL: '/media/local/Chime.mp3?authSig=XYZ'. (Linux UPnP/1.0 Sonos/79.1-53290 (ZPS16))
Login attempt or request with invalid authentication from 10.10.100.156 (10.10.100.156). Requested URL: '/media/local/Chime.mp3?authSig=XYZ'. (Linux UPnP/1.0 Sonos/79.1-53290 (ZPS16))
Login attempt or request with invalid authentication from 10.10.100.117 (10.10.100.117). Requested URL: '/media/local/Chime.mp3?authSig=XYZ'. (Linux UPnP/1.0 Sonos/79.1-53290 (ZPS16))
Login attempt or request with invalid authentication from 10.10.100.227 (10.10.100.227). Requested URL: '/media/local/Chime.mp3?authSig=XYZ'. (Linux UPnP/1.0 Sonos/79.1-53290 (ZPS16))

[derekcentrico]

HA 2024.6.4

Same issue potentially. I get a flood of "failed" login attempts from my Sonos speaker. Just started happening yesterday after installing Chime TTS. Before, I didn't have HA interacting with my Sonos speakers.

2024-06-24 17:20:55.946 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from 192.168.1.94 (192.168.1.94). Requested URL: '/media/local/sounds/temp/chime_tts/xchgu2w2.mp3?authSig=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJiNTI2ZWNjMjlhOTg0ZGJhYjc3MmI0MjkzNDk1ZDc5YiIsInBhdGgiOiIvbWVkaWEvbG9jYWwvc291bmRzL3RlbXAvY2hpbWVfdHRzL3hjaGd1MncyLm1wMyIsInBhcmFtcyI6W10sImlhdCI6MTcxOTE2MzI5OCwiZXhwIjoxNzE5MjQ5Njk4fQ.l0Jd-U4a2E-iPHCEv-rbbCfWdSRRXyrdvetENhzXXvI'. (Linux UPnP/1.0 Sonos/79.1-53290 (ZPS31))

[timiman]

Same issue again for me, too, after 1 month or so. Cannot determine the root of this issue. I'm afraid of the Sonos speaker getting a http ban and won't be able to work as an 'announcer' of events. I've tried to play a sound file from my HA media folder -like the previous time- but this time did not fix the issue.