Skip to content

Subsonic, Workaround for using DSub 5.4.4

Jump to bottom
Pauli Järvinen edited this page Oct 20, 2020 · 5 revisions

Edit: DSub version 5.5.1 offers an option to disable sending Authentication headers which should be the preferred method to solve the problem described below. The details of the workaround are preserved here mostly for historic reasons.

DSub 5.4.4 does not work properly with the Music app because it sends the Authentication header with each of its API calls. This is not part of the Subsonic API definition, but apparently, some DSub users have found it useful in certain proxy configurations. On ownCloud/Nextcloud, this causes a serious problem because we use different password on the Subsonic API compared to the one used to log in to the cloud. When the cloud core sees the Authorization header, it tries to log in the user using the Subsonic password. This of course fails, and after a few more failed log-in attempts, the brute-force protection mechanism blocks any further calls from DSub.

It is possible to work around this issue by setting the cloud password to be the same as the (generated) Subsonic password. You should note, though, that Subsonic passwords are not handled as securely as your standard cloud passwords. They may be sent over the network in insecure manner and they may be visible in the server logs. To minimize the security impact, you should implement the work-around with the following steps:

  1. Create a new ownCloud/Nextcloud user (called "dsub-user" in the following steps)
  2. As your main user, share your music folder in read-only mode with dsub-user
  3. As dsub-user, scan your music collection, and generate a Subsonic API password
  4. Change the cloud password for dsub-user to be the same as the previously generated password
  5. Set up the DSub 5.4.4 client using username dsub-user and the generated password
Clone this wiki locally