Sonarr: Allow basic auth to be configured for download clients

Created on 1 Oct 2018  路  1Comment  路  Source: Sonarr/Sonarr

Describe the problem

I have a download client running on a server somewhere that uses a reverse proxy with HTTP basic auth for access control. I want Sonarr to be able to access that download client.

Describe any solutions you think might work

I'm willing to do the work and submit a PR to enable this, if it's welcome. I can think of two ways to do this, each with some pros and cons:

  1. Add configuration fields for basic auth username/password in each <client>Settings.cs, and add the ability to read those settings (if present) and add them to <client>Proxy.BuildRequest
  2. Modify NzbDrone.Common.Http.[HttpUri,HttpRequestBuilder] to allow parsing the URI-encoded basic auth format (https://user:[email protected]).
  • Option 1 pros:

    • Adding the code for any given download client is straightforward and won't touch the rest of the code base

  • Option 1 cons:

    • Need to manually add the fields for each download client
    • Not very DRY
    • The new fields might be confusing for some users. For example, in the qBittorrent download client, there would now be fields for Username, Password, Basic Auth Username, Basic Auth Password. (Help text and/or hiding the options behind an "enable basic auth" checkbox could maybe mitigate this)
  • Option 2 pros:

    • Instant benefit across the codebase, no new interface elements needed
    • Would not require any new UI elements, and wouldn't confuse users: power users that need the feature would be able to discover it on their own, but the UX for people who don't need the feature wouldn't change
  • Option 2 cons:

    • Making a change in a core shared module is more risky

    • Changes are overall more complicated, compounding the risk

I'm willing to put together a PR for either approach, if I could get some indication that it's likely to be accepted.

>All comments

Thanks for the thorough write up, but I don't think this is something we want to support, clients already support their own internal authentication methods (username/password, API Key, etc), anything external to that isn't something we want to concern Sonarr with and wouldn't be used for the vast majority of users, resulting in us needing to support something we don't get much feedback on.

Perhaps a proxy or a way to allow Sonarr to bypass will fit into your configuration.

Was this page helpful?
0 / 5 - 0 ratings