Add an Option Not to Send HTTP Authentication Request Header

[jeremer2]

I have a proxy server in front of my Subsonic server for SSL and other reasons. I am unable to connect from DSub to Subsonic because DSub sends the Subsonic Username & Password in an HTTP Authentication Request Header which the proxy server attempts to authenticate and fails since this is the Subsonic user information not the proxy server authentication information.

If no HTTP Authentication Request Header is sent, the proxy server allows the request as I have anonymous authentication enabled (in addition to basic authentication).

The Subsonic Android client does not send the header and this configuration works.

For those with a similar issue the work around is to create a user on the proxy server with the same credentials as the Subsonic user. While not ideal, as this creates an administrative hassle, it works.

[paulijar]

The Authentication Request header is a problem also when using ownCloud/Nextcloud Music as your Subsonic server. This is because there, the password used with the Subsonic API is not the same password as the user uses to log in to her cloud account. When the cloud core sees the Authentication Request, it tries to use the Subsonic API password for account login, and that of course fails.

[magneticflux-]

The issue seems to have been introduced in this commit: ed010a2

[magneticflux-]

Here's a patch that fixes the issue:

Index: app/src/main/java/github/daneren2005/dsub/service/RESTMusicService.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- app/src/main/java/github/daneren2005/dsub/service/RESTMusicService.java	(revision 7aff3fa37b186b40d2ac73508b01628b212be8eb)
+++ app/src/main/java/github/daneren2005/dsub/service/RESTMusicService.java	(date 1601003671458)
@@ -1909,13 +1909,15 @@
 			sslConnection.setHostnameVerifier(selfSignedHostnameVerifier);
 		}
 
-		SharedPreferences prefs = Util.getPreferences(context);
-		int instance = getInstance(context);
-		String username = prefs.getString(Constants.PREFERENCES_KEY_USERNAME + instance, null);
-		String password = prefs.getString(Constants.PREFERENCES_KEY_PASSWORD + instance, null);
-		if (prefs.getBoolean(Constants.PREFERENCES_KEY_ENCRYPTED_PASSWORD + instance, false)) password = KeyStoreUtil.decrypt(password);
-		String encoded = Base64.encodeToString((username + ":" + password).getBytes("UTF-8"), Base64.NO_WRAP);;
-		connection.setRequestProperty("Authorization", "Basic " + encoded);
+		if(url.contains("getUser")) {
+			SharedPreferences prefs = Util.getPreferences(context);
+			int instance = getInstance(context);
+			String username = prefs.getString(Constants.PREFERENCES_KEY_USERNAME + instance, null);
+			String password = prefs.getString(Constants.PREFERENCES_KEY_PASSWORD + instance, null);
+			if (prefs.getBoolean(Constants.PREFERENCES_KEY_ENCRYPTED_PASSWORD + instance, false)) password = KeyStoreUtil.decrypt(password);
+			String encoded = Base64.encodeToString((username + ":" + password).getBytes("UTF-8"), Base64.NO_WRAP);;
+			connection.setRequestProperty("Authorization", "Basic " + encoded);
+		}
 
 		// Force the connection to initiate
 		if(connection.getResponseCode() >= 500) {

[paulijar]

Out of curiosity, what is the rationale of sending the HTTP Authentication Request Header in the first place? And why is it sufficient to send it only with the getUser request?

[daneren2005]

The request header is sent because I had quite a few people who wanted to have a basic auth challenge in a proxy in front of Subsonic. I also have no idea what changing it to only be for the getUser request is for though.

[paulijar]

Okay, thanks for the explanation. It still is a bit odd thing to do, since as far as I know, no other Subsonic client out there does that.

As I have mentioned above, sending the authentication header breaks the compatibility with the Nextcloud server. There are many security reasons which prevent us from using the same password for Subsonic API as is used as the "main password" of the Nextcloud user. Not least of these is that we don't want to grant full access to all user data in the cloud but only to the music files under a specified folder.

Now, when Nextcloud sees the repeated login attempts with an incorrect password, it very soon concludes that this is a brute force attack, and blocks the client IP. Hence, the Nextcloud users can't use the latest versions of DSub as their Subsonic client. This is a shame as DSub is by far the most feature-rich available alternative.

[daneren2005]

It shouldn't be hard to drop the auth header from requests that are going to the Subsonic like API

[popeen]

Wouldn't the best thing here be to add a checkbox to the server settings where this can be turned on/off?
I mean I agree that servers that emulate the Subsonic API shouldn't have this problem but even if they fix it that doesn't solve the original problem that this could occur because of reverse proxies.

I have just implemented a setting like this in Booksonic, do you want me to backport it to DSub and submit a pull request or do you want to keep it as is?

[daneren2005]

Yes if you already coded a checkbox that would be the best option.

[popeen]

I have tested this specifically against the Music app for NextCloud and it works fine one thing I noticed however is that the test connection button stops working if the server has a self signed certificate. Actually browsing and listening still works fine with a self signed cert.

Never mind, this was a problem on my end, this should work fine

[paulijar]

It shouldn't be hard to drop the auth header from requests that are going to the Subsonic like API

It's not quite that simple, as the situation is like this:

As the developer of the Music app, I only have direct control over things happening in the "green box" but the requests with the auth headers are reflected already by the Nextcloud server. Now, I could of course try to offer some PR to the Nextcloud core to fix this, but I don't know how willing they would be to create exceptions for an individual use case of an individual app. After all, from their point of view, it is not normal that someone is repeatedly trying to authenticate with an incorrect password.

Another alternative would be to drop the offensive auth header in the WWW server configuration, but then it would be up to each server admin to make this configuration. And some people are probably running Nextcloud on some hosted server, with no access to the web server configuration files.

But having a checkbox to disable the auth header sending will be perfect. Thanks @popeen for this!

[paulijar]

I just tested DSub 5.5.1 with the option to disable the auth headers, and it works great. I believe that this issue can be closed now.