[Feature Request] Allow Fixed Server/Username/Password for LAN Play via an .env

[kobayashi90]

basically what the title says.

[Tina-otoge]

Not sure if that would be covered by the same request, but I basically want to be able to specify server + username + password in env so that when we open the web app, we are directly connected to the specified account. I don't want the feature to be limited to LAN environments.

My use case is to default to a "guest" account I have on my Subsonic server. So that I would be able to send links to albums or playlists without requiring people to login.

This is what I'm already doing with https://github.com/victoralvesf/aonsoku, but since it doesn't support mobile devices, I want to try switching to Airsonic Refix, but not having support for this feature is currently a blocker for me.

[tamland]

Adding a password to .env will expose it publicly making the password pointless. Perhaps this should be discussed at open-subsonic so it can work across servers?

[Tina-otoge]

This indeed nullifies the purpose of the password (API token in this case) for the specified account, as I am aware the token will be exposed to the user since it will be bundled into Airsonic's env. This is the intended behavior in my use case. The user get thrown in a guest account which has access to the library. I don't know how all Subsonic servers handle this, but I use LMS and the user is not able to perform any administrative actions or change his API token by using his access to the Subsonic API. So this effectively creates a "read-only" way to access the library. This is how I have it currently set up with Aonsoku which supports this. But for reasons stated above, I'd like to move to Airsonic.

If the user wants to use another account on Airsonic, he should be able to disconnect like usual and then be redirected to the login form.

My use case is to allow easy access to the guest account I have on my Subsonic server, so that can I can share it without making people enter the guest credentials manually.

For @kobayashi90's use case I think Airsonic is only exposed on their LAN, and all devices on their LAN are already trusted, so having to enter creds to access the platform creates an additional bother.

The same thing would occur for users who have authentication handled at a higher level, such as using an SSO that then proxies the requests to Airsonic once the user is authenticated.

[kobayashi90]

Adding a password to .env will expose it publicly making the password pointless. Perhaps this should be discussed at open-subsonic so it can work across servers?

Docker Secrets exists tho, so no.. nothing happens at all.

For @kobayashi90's use case I think Airsonic is only exposed on their LAN, and all devices on their LAN are already trusted, so having to enter creds to access the platform creates an additional bother.

Exactly. I have people at home at wanna listen to their Music easily but have no idea of how Computers work.

Not sure if that would be covered by the same request, but I basically want to be able to specify server + username + password in env so that when we open the web app, we are directly connected to the specified account. I don't want the feature to be limited to LAN environments.

Yeah i think we have the same issue friend. Its an big issue that most of almost all Navidrome/Subsonic clients have some kind of barrier of entry.. its suppose to be easy to use yet it has so many hardships.

[Tina-otoge]

Adding a password to .env will expose it publicly making the password pointless. Perhaps this should be discussed at open-subsonic so it can work across servers?

Docker Secrets exists tho, so no.. nothing happens at all.

Docker Secrets allows you to use secrets and hide them at the infra / configuration level. But the way Airsonic or any web frontend works, is that the secret will inevitably end up being bundled with the web files and be visible to anyone accessing the application.

For example, on your public Aonsoku instance @kobayashi90, if I go to the URL /env-config.js, I can see the user and password for the guest account you created, in plain text.

I think the concern that @tamland raised is that if you embed the secret in the web app, to perform automatic logins, obviously the secret will be exposed to all clients (browsers) accessing the app. And administrators may not realize this when they configure the application.

For me, I totally understand this and this is the desired outcome, but I think it's important to document properly alongside each mention of the variable in the documentation, that setting a default user/password WILL make it public to anyone accessing the web application.

As long as it is properly documented, I think this is a very useful feature to have.

[kobayashi90]

For example, on your public Aonsoku instance @kobayashi90, if I go to the URL /env-config.js, I can see the user and password for the guest account you created, in plain text.

Even if someone does that, most people would if not everyone wont be an idiot and use an user login that does have admin priviledges.. and even if someone does that.. thats on themselfs.. its not up the developers to hand hold people.
I know that sounds harsh but developers cant avoid everything happening to you "the user" in terms of security.
Even if they should do.

You get what i mean, its just sad we have this conversation even.. i just want to use the interface publicly (in terms of an LAN) and dont have to worry about having an security problem. Also again even if the interface is openly public, as long as they cant mess around with the people data (eg. Music) everything is fine as it is.

Also dont get me wrong i am not hating on the App, its just normal criticism about the current state of Navidrome/Subsonic Clients in general.

[tamland]

I agree that a guest feature should be a thing in the whole subsonic universe, which it is not currently.

But servers should rather just support authenticating anonymously or without password instead of hard-coding fake-secure credentials in clients.