Replies: 2 comments
|
If you can figure out how to make the stream work I'd gladly review a PR and get this merged in. However as you mentioned it may require some significant reworking since the MPV player backend currently fetches the URLs itself, and I'm not sure if there's a way to tell MPV to add headers to the HTTP request. So in the worst case it might require that Supersonic proxy the request, and then you'll also have to deal with the range headers and other niceties MPV does to be able to efficiently seek within the track when it is playing without transcoding. |
|
Actually it looks like MPV does support basic auth. According to ChatGPT it will automatically handle stream URLs like If that doesn't work, you can call the |
Uh oh!
There was an error while loading. Please reload this page.
I have Navidrome behind a proxy authentication SSO - the proxy is responsible for authentication, and Navidrome trusts the auth headers set by the proxy and ignores Subsonic authentication. This works fine in the browser, since the browser has all the necessary mechanics to obtain a token cookie via redirects, which it will add to future requests when using the application.
For applications like Supersonic, the simplest workaround is to use HTTP Basic Authentication with an App Password created in the SSO provider (to avoid the MFA flows which require a browser). However, this requires that the application set the Basic Auth header on all requests so the proxy can authenticate them. Since Subsonic uses its own authentication protocol instead of HTTP Basic Auth, this is 'extra' authentication information that needs to be added.
This is supported in Symfonium's Subsonic client for example. When enabled, it simply adds the same username/password to an HTTP Basic Auth header.
I thought this would be trivial so I went ahead and implemented this in your fork of
go-subsonicand insupersonicitself with a toggle in the server settings. And it works fine for Library/UI requests. However it doesn't work for playback because the playbackEngine is somewhat decoupled from the MediaProvider, and simply queues a URL it fetches itself instead of using the provider's implementation to retrieve the media. I don't believe the user's credentials are easily accessible from this code in the AudioCache.Unfortunately simply allowing proxy bypass on the
/rest/streamendpoint doesn't work either, because then Navidrome doesn't get the headers from the proxy, so believes the request is unauthenticated. I have hacked it for now to bypass auth but set the auth username header anyway, but this isn't great.I'd like to propose a PR including this feature, but it will require a bit of refactoring to move the download requests out of AudioCache and into the MediaProvider, I think.
This is kinda related to #627 , but support for backends with proper oidc/oauth support will look quite different than app passwords + proxy auth and it'd be nice to support both (esp. since Navidrome seems opposed to implementing proper oauth).
All reactions