streams: support reverse-proxy published base URL#3976
Conversation
The streamserver hardcoded `http://` in the published `base_url`. That makes it impossible to run the streamserver behind a TLS-terminating reverse proxy, which is required for some clients — the Sonos S2 controller app for instance silently ignores artwork URLs served over `http://` (App Transport Security on iOS, cleartext-traffic policy on Android) and falls back to its built-in placeholder image. Add a single optional `CONF_PUBLISH_BASE_URL` advanced setting that lets the user override the URL advertised to stream clients with a full URL of the form `scheme://host[:port][/path]` (e.g. `https://music.example.com/streamer`). When empty, falls back to the previous `http://<publish_ip>:<bind_port>` behavior so existing setups are unaffected. `publish_ip` deliberately stays a literal IP — many local-discovery providers (AirPlay, Sendspin, Chromecast, ...) call `inet_pton` / `ipaddress.ip_address` on it. Only the *advertised* URL for stream clients can now diverge.
|
This change is tested and allows me to have proper artwork in my sonos app when playing from music assistant |
|
The problem this solves is cosmetic. Audio plays fine over plain HTTP, the only thing that doesn't work is the album art showing in the Sonos app. If you controlled your music through Music Assistant you would never see a problem. So this only affects people who use the native Sonos app with MA as a background source, and even then it's just a missing thumbnail. To fix that, the change asks the user to run a reverse proxy with HTTPS in front of the stream server, and then it swaps the address MA gives to every player, not just Sonos. That's a potential problem. A lot of local players like Squeezebox and older DLNA speakers can't do HTTPS, so anyone who turns this on to fix the Sonos art could end up breaking audio on their other speakers without realising why. My question is whether this is worth a permanent setting in core. It's a narrow case, it's cosmetic, and MA on its own isn't affected. One alternative is to document a reverse proxy setup for the people who really want it. If we do decide it's worth having, I suggest it should be limited to the Sonos player so it can't affect everyone's other speakers. |
|
This PR goes a bit against our whole recommendation that players should be on the same vLAN (or flat network) as players and the streams server provides a simple, painless way to stream the audio to players. There is a reason that the streamserver does not add HTTPS by default as it adds unneeded overhead and a lot of players even struggle with HTTPS, especially the older ones. Maybe this works for Sonos players but it will fail for others. The whole idea of this streams server being detached from the normal webserver is that we can provide the players on the network this direct connection, without the overhead. Putting the streams server behind a reverse proxy is just a bad idea. So I'm inclined to say that this PR should not be accepted in this form. |
|
In my particular case, my Sonos devices are indeed on a dedicated network distinct from Music Assistant (for security reasons) and it was not too much work to set up an https reverse proxy (not exposed to the internet, of course). Well yes, this is of course cosmetic, but at least for me, it's quite nice to have proper icons in the Sonos app when playing from Music Assistant, and the code change is both really minor, hidden under advanced options, and a quality-of-life improvement... why not? I'm willing to change this into another form that would make this acceptable if you think this may either introduce confusion or issues for existing users (personally I think the stream configuration is already quite confusing / reserved for advanced users anyway). |
|
But the streams server shouldn't be behind a reverse proxy at all. I'm afraid if we add this, we will run into situations where people have issues with audio because of the reverse proxy in between (which we cant control). |
|
You're right indeed.. What about a separate setting for the artwork then ?
Would that make more sense ? Perhaps making this sonos-specific if possible
(did not look into that yet).
Le mer. 27 mai 2026 à 09:58, Marcel van der Veldt ***@***.***>
a écrit :
… *marcelveldt* left a comment (music-assistant/server#3976)
<#3976 (comment)>
But the streams server shouldn't be behind a reverse proxy at all.
Streams server = local network only, direct connection to the players. You
can even decide to have your setup multi-homed so the streams server sits
on your IoT interface.
I'm afraid if we add this, we will run into situations where people have
issues with audio because of the reverse proxy in between (which we cant
control).
—
Reply to this email directly, view it on GitHub
<#3976?email_source=notifications&email_token=AAGDO6F6KWWT4R7BMA5YUJT442N3VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJVGI3DANRSGEY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4552606211>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGDO6G7SZGOT5EP3S6NULL442N3VAVCNFSM6AAAAACZMB4UY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNJSGYYDMMRRGE>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
3 participants
The streamserver hardcoded
http://in the publishedbase_url. That makes it impossible to run the streamserver behind a TLS-terminating reverse proxy, which is required for some clients — the Sonos S2 controller app for instance silently ignores artwork URLs served overhttp://(App Transport Security on iOS, cleartext-traffic policy on Android) and falls back to its built-in placeholder image.Add a single optional
CONF_PUBLISH_BASE_URLadvanced setting that lets the user override the URL advertised to stream clients with a full URL of the formscheme://host[:port][/path](e.g.https://music.example.com/streamer). When empty, falls back to the previoushttp://<publish_ip>:<bind_port>behavior so existing setups are unaffected.publish_ipdeliberately stays a literal IP — many local-discovery providers (AirPlay, Sendspin, Chromecast, ...) callinet_pton/ipaddress.ip_addresson it. Only the advertised URL for stream clients can now diverge.What does this implement/fix?
Types of changes
bugfixnew-featureenhancementnew-providerbreaking-changerefactordocumentationmaintenancecidependenciesChecklist
pre-commit run --all-filespasses.pytestpasses, and tests have been added/updated undertests/where applicable.music-assistant/modelsis linked.music-assistant/frontendis linked.