Reverse proxy configuration doesn't work with 5.2.0 #24184
Description
Activity
I don't use reverse proxy for myself. But the following test config works fine with qBittorrent 5.2 for me:
location /qbt/ {
proxy_pass https://127.0.0.1:8088/;
proxy_http_version 1.1;
# headers recognized by qBittorrent
proxy_set_header Host $proxy_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
}Hi.
Not local, not IPv4.
- nginx part:
...
location /PATH/ {
auth_basic "CENSORED";
auth_basic_user_file qbt-auth;
### Needed for debug output.
# set $upstream http://[fdb9:1981:930:3::1:1]:18181/;
proxy_pass http://[fdb9:1981:930:1::5:6]:18181/;
### Doesn't work for some reason.
# proxy_pass $upstream;
proxy_http_version 1.1;
# proxy_set_header Host [fdb9:1981:930:1::5:6]:18181;
proxy_set_header Host $proxy_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cookie_path / "/; Secure";
}
...
- qbittorrent part (in this case built from git, but 5.2.0 behavior is the same):
...
WebUI\Address=fdb9:1981:930:1::5:6
WebUI\AuthSubnetWhitelistEnabled=true
WebUI\CSRFProtection=true
WebUI\ClickjackingProtection=true
WebUI\CustomHTTPHeaders=
WebUI\CustomHTTPHeadersEnabled=false
WebUI\HTTPS\CertificatePath=/etc/cert/hosts/local.crt
WebUI\HTTPS\Enabled=false
WebUI\HTTPS\KeyPath=/etc/cert/hosts/local.key
WebUI\HostHeaderValidation=false
WebUI\LocalHostAuth=false
WebUI\MaxAuthenticationFailCount=5
WebUI\Password_PBKDF2="CENSORED"
WebUI\Port=18181
WebUI\ReverseProxySupportEnabled=true
WebUI\ServerDomains=*
WebUI\TrustedReverseProxiesList=fdb9:1981:0930:1::1:1/48
WebUI\UseUPnP=true
WebUI\Username=CENSORED
...
nginx running on the host with IP fdb9:1981:0930:1::1:1 (though the host has several IPv6 ULA addresses from fdb9:1981:0930::/48 network).
Version 5.1.4 was working just fine with this configuration (on another host):
WebUI\Address=fdb9:1981:930:3::1:1
WebUI\AlternativeUIEnabled=false
WebUI\AuthSubnetWhitelistEnabled=false
WebUI\BanDuration=3600
WebUI\CSRFProtection=true
WebUI\ClickjackingProtection=true
WebUI\CustomHTTPHeaders=
WebUI\CustomHTTPHeadersEnabled=false
WebUI\HTTPS\CertificatePath=/etc/cert/hosts/local.crt
WebUI\HTTPS\Enabled=false
WebUI\HTTPS\KeyPath=/etc/cert/hosts/local.key
WebUI\HostHeaderValidation=true
WebUI\LocalHostAuth=true
WebUI\MaxAuthenticationFailCount=5
WebUI\Password_PBKDF2="CENSORED"
WebUI\Port=18181
WebUI\ReverseProxySupportEnabled=false
WebUI\RootFolder=
WebUI\SecureCookie=true
WebUI\ServerDomains=*
WebUI\SessionTimeout=3600
WebUI\TrustedReverseProxiesList=
WebUI\UseUPnP=false
WebUI\Username=CENSORED
I ran into the same issue with Traefik + oauth2-proxy.
Looks like dda7f80 ("WebUI: Support authenticating via Basic auth", PR #23564) changed how it handles Authorization header.
In v5.1.4, Authorization header was only checked for API key detection.
In v5.2.0, it's now always parsed.
So any reverse proxy that forwards Authorization header to the backend (nginx auth_basic, oauth2-proxy, etc.) will break.
Here is the fix for your nginx config if you want to keep auth_basic:
proxy_set_header Authorization "";
For developers: should
proxy_set_header Authorization "";
be added to the official recommendations for nginx reverse proxy configuration?
For developers: should
proxy_set_header Authorization "";be added to the official recommendations for nginx reverse proxy configuration?
@Piccirello, ping!
It really depends on how the user would like to handle authentication. I'm not in front of a computer right now, but I believe setting proxy_set_header Authorization "" will cause qBittorrent to handle auth. That means either via qBittorrent's login page, an API key, or subnet whitelist. Whereas if someone would like the proxy to handle auth, they should set Authorization to the base64 encoded qBittorrent username and password.
It is possible that the same problem also happens when mapping ports within a container:
Without port mapping:
$ podman run --rm -p 8080:8080 -e WEBUI_PORTS="8080/tcp" ghcr.io/hotio/qbittorrent
$ curl http://localhost:8080
<!DOCTYPE html>
...
</html>With port mapping:
$ podman run --rm -p 9000:8080 -e WEBUI_PORTS="8080/tcp" ghcr.io/hotio/qbittorrent
$ curl http://localhost:9000
UnauthorizedThis doesn't seem correct to me though... It should work transparently.
@Chocobo1, I tried both, but as they are not well documented I might have made a mistake in the configuration.
Right now I have the following in the nginx configuration
...
location /HOST/ {
auth_basic "INFO";
auth_basic_user_file qbt-auth;
### Needed for debug output.
# set $upstream http://[fdb9:1981:930:3::1:7]:18181/;
proxy_pass http://[fdb9:1981:930:3::1:7]:18181/;
### Doesn't work for some reason.
# proxy_pass $upstream;
proxy_http_version 1.1;
# proxy_set_header Host [fdb9:1981:930:3::1:7]:18181;
proxy_set_header Host $proxy_host;
# ### See https://github.com/qbittorrent/qBittorrent/issues/24184
proxy_set_header Authorization "";
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cookie_path / "/; Secure";
}
...
and the following in qBittorrent.conf:
...
WebUI\Address=fdb9:1981:930:3::1:7
...
WebUI\HostHeaderValidation=false
WebUI\LocalHostAuth=false
...
WebUI\Port=18181
WebUI\ReverseProxySupportEnabled=true
...
WebUI\TrustedReverseProxiesList=fdb9:1981:0930:3::1:1/64
...
but without proxy_set_header Authorization ""; I get unauthorized when opening the URL.
The host running qbittorrent has the address fdb9:1981:0930:3::1:7 (among others), and the host running nginx has the address fdb9:1981:0930:3::1:1.
I could be wrong, but I think what @Piccirello said could be correct.
Besides, as I mentioned above, the same configuration for 5.1.4 works fine. That doesn't mean it was correct, but it suggests that the reverse proxy configuration for the 5.2.0 version needs clarification.
@vp1981 I have been checking the code and:
- You don't need
WebUI\ReverseProxySupportEnabled=trueunless you want to specify a list of supported proxies, in which case qBittorrent will check theX-Forwarded-Host. If you only have one proxy, you can disable this and also remove theX-Forwarded-Hostheader from nginx. - If you have
WebUI\HostHeaderValidation=false, then you don't needproxy_set_header Host $proxy_host;
I believe that you can go back to your "old" configuration and simply add the proxy_set_header Authorization "" if you want nginx to handle your basic auth.
Metadata
Metadata
Assignees
Type
Fields
Give feedbackProjects
Milestone
Relationships
Development
Participants
qBittorrent & operating system versions
Archlinux x86_64
qbittorrent: 5.2.0
qt: 6.11
libtorrent-rasterbar: 2.0.12
What is the problem?
The standard reverse proxy configuration for nginx has stopped working, and now I see "Unauthorized".
Steps to reproduce
No response
Additional context
No response
Log(s) & preferences file(s)
Excerpt from
~/.config/qBittorrent/qBittorrent.conf