WebUI: Support authenticating via Basic auth

[Piccirello]

This PR adds support for authenticating to the WebAPI via Basic auth. Failed login accounting and IP banning works identically for basic auth and the login page.

Closes #13238.
Closes #15007.

[glassez]

@Piccirello
I have some preliminary questions.

1. Aren't both Support basic auth #15007 and WebUI: Single Sign-On with Traefik #13238 about WebUI, not about WebAPI only?
2. What's the point in supporting all of the auth methods?
3. What's the benefit of Basic auth over other supported methods?
4. If some of the auth methods are clearly preferred/best, shouldn't we abandon the rest to please them instead of trying to please them all?

[Piccirello]

1. Aren't both Support basic auth #15007 and WebUI: Single Sign-On with Traefik #13238 about WebUI, not about WebAPI only?

This PR mostly modifies the WebAPI, but it's to support usage of the WebUI. I'll add the WebUI label to this PR.

2. What's the point in supporting all of the auth methods?
3. What's the benefit of Basic auth over other supported methods?

Each of these auth methods is for a slightly different use case.

The login page is the most basic auth method and works out of the box, without further configuration. It's for WebUI clients that want to access the WebAPI.

Basic auth is more advanced and allows the user to shift responsibility for authenticating from the browser to their reverse proxy. It makes it easier to access the WebUI through a central proxy (e.g. nginx/traefik), including from multiple browsers/devices, by having the proxy send a Basic auth header. I personally use a reverse proxy and have done so for many years. On my network my devices authenticate once to my reverse proxy (via mTLS), and then I can access all my internal sites/tools without having to authenticate again to each individual tool.

API key auth (Bearer auth) is exclusively for WebAPI usage. It's meant for third party tools that interact with the WebAPI. It's stateless and doesn't use a cookie. It does not allow access to WebUI assets.

4. If some of the auth methods are clearly preferred/best, shouldn't we abandon the rest to please them instead of trying to please them all?

Each of the three supported auth methods is for a distinct use case. With this PR, I believe we now solve for all requested use cases. I don't foresee us needing to support an additional auth method in the future (or at least no one is asking for one yet).

[glassez]

Basic auth is more advanced

This looks weird. Isn't Basic auth a most primitive one?
Moreover, my limited knowledge in this area tells me that Basic auth is supposed to be used in other scenarios than the ones with sessions (isn't Basic auth header supposed to be sent in every request?).

[Piccirello]

Basic auth is more advanced

This looks weird. Isn't Basic auth a most primitive one? Moreover, my limited knowledge in this area tells me that Basic auth is supposed to be used in other scenarios than the ones with sessions (isn't Basic auth header supposed to be sent in every request?).

What I mean is that it's a more advanced use case, in that it requires additional configuration (and the use of a reverse proxy).

The Basic auth header doesn't necessarily need to be sent on every request - though it can be. In our case we use the Basic auth header only if there isn't an existing session cookie.

[glassez]

The Basic auth header doesn't necessarily need to be sent on every request - though it can be. In our case we use the Basic auth header only if there isn't an existing session cookie.

But, IIRC, browsers usually do just that, i.e. they continue to send auth header with each subsequent request. Although, as far as I can understand, we do not expect such a use case (authentication using browser), and we do not even send a suitable status, which is supposed to prompt the browser to perform Basic auth... I'm just worried that this kind of "hybrid" authentication won't look unexpected to client applications.

[realnc]

One thing I haven't seen mentioned about basic auth: it allows me to make it impossible to know what I'm running. If I access qbit through https://app.example.com and someone else accesses it, without basic auth they're gonna know right away that it's qbittorrent. With basic auth, they don't know what's running there. It could be anything. All they are able to see is the standard browser login dialog.

Right now, the only way to achieve this is to disable auth on localhost (or local subnet) and enable basic auth in the reverse proxy. But on a shared app host/seedbox, you don't want to disable local auth in qbittorrent, because other users on the same shared host would be able to access it.

[Piccirello]

I'm just worried that this kind of "hybrid" authentication won't look unexpected to client applications.

This isn't something we'll need to worry about at all. Clients won't attempt Basic auth and don't even have to be aware that it's supported. This is purely optional for reverse proxies to use when explicitly configured.

[glassez]

I personally use a reverse proxy and have done so for many years. On my network my devices authenticate once to my reverse proxy (via mTLS), and then I can access all my internal sites/tools without having to authenticate again to each individual tool.

Could you provide a description of how someone could set up a similar environment for their own review/testing?

[glassez]

Clients won't attempt Basic auth and don't even have to be aware that it's supported. This is purely optional for reverse proxies to use when explicitly configured.

Why not? If it's available, why wouldn't some 3-rd party client developer want to use it in their client? You can't restrict it. That's what I'm talking about.
It doesn't mean that I dissaprove it. It's just that it might be worth mentioning its specific purpose/behavior somewhere in the WebUI documentation.

[Piccirello]

Could you provide a description of how someone could set up a similar environment for their own review/testing?

You can test this using the sample nginx config below. This will result in you connecting to your nginx server, and the nginx server authenticating to qBittorrent in a manner completely transparent to your browser.

First you'll need to generate your basic auth header value using echo -n "username:password" | base64, replacing the username and password with your qBittorrent WebUI credentials. Then substitute your qBittorrent server's IP address and the base64 value into the config below.

    upstream qbit {
      # TODO replace with your IP
      server 127.0.0.1:8080 fail_timeout=0;
    }

    server {
      listen 80;

      server_name qbit.example.com;

      location / {
        proxy_pass http://qbit/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;

        # TODO replace with your base64 encoded credentials
        proxy_set_header Authorization "Basic YOUR_BASE64_VALUE";

        proxy_hide_header Origin;
        proxy_hide_header Referer;
        proxy_set_header Origin '';
        proxy_set_header Referer '';
      }
    }

[Piccirello]

Resolved merge conflict.

[Piccirello]

I wrote up some basic docs on using basic auth.

https://github.com/qbittorrent/qBittorrent/wiki/Basic-Authentication-(≥v5.2.0)

[glassez]

@Piccirello
Thank you.

[qBittUser]

@Piccirello #23564 (comment)

Wiki mentions that v2.15.0 is required, but WebAPI Changelog currently shows v2.14.1 as latest:

https://github.com/qbittorrent/qBittorrent/blob/master/WebAPI_Changelog.md

Also looking at the commit history of the webapplication.h file I noticed another PR by was previously merged and @glassez commit 93470f2#diff-13474ccd513f95826cbe8c120f2b739c0461d6d05a67fbaf6be8143a6f9d55c7 already updated WebAPI version to v2.15.0, but not mentioned in the WebAPI changelog file.

[Piccirello]

Addressed in #23709

[Chocobo1]

I wrote up some basic docs on using basic auth.

https://github.com/qbittorrent/qBittorrent/wiki/Basic-Authentication-(≥v5.2.0)

@Piccirello
Please read the top header of the wiki page. Here I quote it for you:

The wiki source code is hosted at https://github.com/qbittorrent/wiki and is accepting Pull Requests.

You should not edit the wiki via the Edit button anymore, but head to the repo and submit your changes over there.