WebUI does not open with Firefox (Removing the trailing slash then loads the full UI) #8484

Author

Owner

@WeirDave commented on GitHub (Mar 27, 2019):

I am on Windows 10. It works fine for me on Chrome but not in Firefox

@WeirDave commented on GitHub (Mar 27, 2019): I am on Windows 10. It works fine for me on Chrome but not in Firefox

deekerman commented

Author

Owner

@jobrien2001 commented on GitHub (Mar 28, 2019):

Opens fine for me on 66.0.2 on win 10

@jobrien2001 commented on GitHub (Mar 28, 2019): Opens fine for me on 66.0.2 on win 10

deekerman commented

Author

Owner

@WeirDave commented on GitHub (Mar 28, 2019):

Okay what can I do to fix?

@WeirDave commented on GitHub (Mar 28, 2019): Okay what can I do to fix?

deekerman commented

Author

Owner

@facemanak commented on GitHub (Mar 31, 2019):

The same issue occurs for me:
FF 66.0.2 (64-bit)
qBittorrent 4.1.3 (64-bit)

I enter my credentials, click [Login] button and then the page is only refreshed. But right after the first step - restarting FF let's me in without entering my credentials.

Edge works just fine, but FF is my primary browser.

@facemanak commented on GitHub (Mar 31, 2019): The same issue occurs for me: FF 66.0.2 (64-bit) qBittorrent 4.1.3 (64-bit) I enter my credentials, click [Login] button and then the page is only refreshed. But right after the first step - restarting FF let's me in without entering my credentials. Edge works just fine, but FF is my primary browser.

deekerman commented

Author

Owner

@adem4ik commented on GitHub (Mar 31, 2019):

qBittorrent 4.1.3 (64-bit)

The latest version is 4.1.5.

@adem4ik commented on GitHub (Mar 31, 2019): > qBittorrent 4.1.3 (64-bit) The latest version is 4.1.5.

deekerman commented

Author

Owner

@WeirDave commented on GitHub (Mar 31, 2019):

I have 4.1.5

@WeirDave commented on GitHub (Mar 31, 2019): I have 4.1.5

deekerman commented

Author

Owner

@facemanak commented on GitHub (Mar 31, 2019):

Oh, sorry for mixing up things. I checked the version again and it is 4.1.5 (v4.1.3 is on my laptop)
I'm using the latest version on my HTPC as well.
I would like to add that Android FF 66.0.2 doesn't have this issue. Web UI opens as expected after I click [Login] button from the first attempt.

@facemanak commented on GitHub (Mar 31, 2019): Oh, sorry for mixing up things. I checked the version again and it is 4.1.5 (v4.1.3 is on my laptop) I'm using the latest version on my HTPC as well. I would like to add that **Android** FF 66.0.2 doesn't have this issue. Web UI opens as expected after I click [Login] button from the first attempt.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Mar 31, 2019):

Cannot reproduce on Ubuntu 18.04 LTS or Windows 10.

@FranciscoPombal commented on GitHub (Mar 31, 2019): Cannot reproduce on Ubuntu 18.04 LTS or Windows 10.

deekerman commented

Author

Owner

@adem4ik commented on GitHub (Mar 31, 2019):

I have the only idea - WebUI might be cached from the previous version, so you may try to perform full refresh by pressing CTRL+F5/CTRL+R or cleaning up browser's cache.

@adem4ik commented on GitHub (Mar 31, 2019): I have the only idea - WebUI might be cached from the previous version, so you may try to perform full refresh by pressing CTRL+F5/CTRL+R or cleaning up browser's cache.

deekerman commented

Author

Owner

@WeirDave commented on GitHub (Mar 31, 2019):

I have cleaned out the entire history, and cookies and it still doesn't load. To be clear the login appears. You login. It goes right back to the login. It's still working in Chrome and Edge

@WeirDave commented on GitHub (Mar 31, 2019): I have cleaned out the entire history, and cookies and it still doesn't load. To be clear the login appears. You login. It goes right back to the login. It's still working in Chrome and Edge

deekerman commented

Author

Owner

@facemanak commented on GitHub (Mar 31, 2019):

OK, it seems I have just resolved the issue:
I have uninstalled my FF browser completely. Probably this was not really required, but to be sure I have also removed some traces that were left within Registry after the uninstall process was completed.
Then fresh FF install, sync configuration and now it works as expected.

I will keep observing WebUI functionality within my FF browser and let you know if the issue comes back.

Anyways, I would like to thank everybody who tried to help and didn't just passed by the problem.

@facemanak commented on GitHub (Mar 31, 2019): OK, it seems I have just resolved the issue: I have uninstalled my FF browser completely. Probably this was not really required, but to be sure I have also removed some traces that were left within Registry after the uninstall process was completed. Then fresh FF install, sync configuration and now it works as expected. I will keep observing WebUI functionality within my FF browser and let you know if the issue comes back. Anyways, I would like to thank everybody who tried to help and didn't just passed by the problem.

deekerman commented

Author

Owner

@facemanak commented on GitHub (Apr 2, 2019):

Hi,
bad news. The same day later Web UI issue returned. My next decision was to downgrade qBittorrent from v4.1.5 to v4.1.0. And for now Web UI is always accessible and works without any issues.

I have started using qbittorrent from 8/2018 and it used to work perfectly without any issues. But starting from January/February the issue with Web UI has started to occur for me.

@facemanak commented on GitHub (Apr 2, 2019): Hi, bad news. The same day later Web UI issue returned. My next decision was to **downgrade** qBittorrent from v4.1.5 to v4.1.0. And for now Web UI is always accessible and works without any issues. _I have started using qbittorrent from 8/2018 and it used to work perfectly without any issues. But starting from January/February the issue with Web UI has started to occur for me._

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Jul 3, 2019):

Have the same issue:

qBittorrent 4.1.6 is installed to Mint 19. Used chrome for a while on Win10x64 then decided to switch to FF (67.0.4 x64). FF loads the login screen if I enter the URL directly but not log me in if I provide my credentials. But:

It still works from chrome from same machine.
It works from FF incognito mode from same machine.
It works from other machines with FF from the same subnet.
Most interesting: it works if I access the login URL from a redirection. Like adding this to a site/local html:
<a href="https://192.168.1.1">qBittorrent site</a>

@aelfwine88 commented on GitHub (Jul 3, 2019): Have the same issue: qBittorrent 4.1.6 is installed to Mint 19. Used chrome for a while on Win10x64 then decided to switch to FF (67.0.4 x64). FF loads the login screen if I enter the URL directly but not log me in if I provide my credentials. But: - It still works from chrome from same machine. - It works from FF incognito mode from same machine. - It works from other machines with FF from the same subnet. - Most interesting: it works if I access the login URL from a redirection. Like adding this to a site/local html: `<a href="https://192.168.1.1">qBittorrent site</a>`

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Jul 5, 2019):

Ok, the FF on my laptop is just stopped working as well. Produces the same issue as above.
Since it's a new install and I set up sync it may synced something that broke it.

@aelfwine88 commented on GitHub (Jul 5, 2019): Ok, the FF on my laptop is just stopped working as well. Produces the same issue as above. Since it's a new install and I set up sync it may synced something that broke it.

deekerman commented

Author

Owner

@0xbbadbeef commented on GitHub (Aug 4, 2019):

I encountered this issue as well, but after logging in under incognito mode it seems to let me log in consistently now for some reason without incognito.

Weird issue 🤔

@0xbbadbeef commented on GitHub (Aug 4, 2019): I encountered this issue as well, but after logging in under incognito mode it seems to let me log in consistently now for some reason without incognito. Weird issue 🤔

deekerman commented

Author

Owner

@Piccirello commented on GitHub (Aug 4, 2019):

I'm not able to reproduce in Firefox (my default browser). Can someone who is facing this issue post a screenshot of any errors reported in their Dev console? The output on the Network tab would be helpful too.

@Piccirello commented on GitHub (Aug 4, 2019): I'm not able to reproduce in Firefox (my default browser). Can someone who is facing this issue post a screenshot of any errors reported in their Dev console? The output on the Network tab would be helpful too.

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Aug 7, 2019):

@Piccirello :
Played around a bit more and the problem just getting even weirded. I found out that the error only occurs if I use a pinned (maybe happens with unpinned as well) link in the "New Tabs" FF page like this:

If I click this link the login page loads and the bug mentioned above appears and just keeps reloading the login page if I try to log in.

For this to reproduce for sure I have to restart my qbittorrent client and firefox because after a some fiddling around sometimes the pinned link start to work correctly like 0xbbadbeef and me mentioned above. However if I restart my qbittorrent client and my firefox the bug appears again 100%.

Also an interesting workaround I just found:
If I open a new tab and type the webui URL by hand and hit enter I can authenticate and always got redirected to my torrents page.

I uploaded FF's console and dev tools output both working and not working cases (my port got masqueraded).
Here you can see as I start FF to the New Tabs tab, click the pinned link and try to authenticate:
notworking_console.txt
notworking_dev_tools.txt

And here you can see as I start FF to the New Tabs tab, enter the url manually and try to authenticate:
working_console.txt
working_dev_tools.txt

Honestly I didn't see too much difference... :\

Also I have the latest FFx64 (68.0.1) and latest qBittorrent (4.1.7) on Mint 19.

@aelfwine88 commented on GitHub (Aug 7, 2019): @Piccirello : Played around a bit more and the problem just getting even weirded. I found out that the error only occurs if I use a pinned (maybe happens with unpinned as well) link in the "New Tabs" FF page like this: ![Capture](https://user-images.githubusercontent.com/4388412/62638215-439cbd80-b93d-11e9-9398-81b752378351.PNG) If I click this link the login page loads and the bug mentioned above appears and just keeps reloading the login page if I try to log in. For this to reproduce for sure I have to restart my qbittorrent client and firefox because after a some fiddling around sometimes the pinned link start to work correctly like 0xbbadbeef and me mentioned above. However if I restart my qbittorrent client and my firefox the bug appears again 100%. Also an interesting workaround I just found: If I open a new tab and type the webui URL by hand and hit enter I can authenticate and always got redirected to my torrents page. I uploaded FF's console and dev tools output both working and not working cases (my port got masqueraded). Here you can see as I start FF to the New Tabs tab, click the pinned link and try to authenticate: [notworking_console.txt](https://github.com/qbittorrent/qBittorrent/files/3478115/notworking_console.txt) [notworking_dev_tools.txt](https://github.com/qbittorrent/qBittorrent/files/3478116/notworking_dev_tools.txt) And here you can see as I start FF to the New Tabs tab, enter the url manually and try to authenticate: [working_console.txt](https://github.com/qbittorrent/qBittorrent/files/3478117/working_console.txt) [working_dev_tools.txt](https://github.com/qbittorrent/qBittorrent/files/3478118/working_dev_tools.txt) Honestly I didn't see too much difference... :\ Also I have the latest FFx64 (68.0.1) and latest qBittorrent (4.1.7) on Mint 19.

deekerman commented

Author

Owner

@Lentolo commented on GitHub (Sep 6, 2019):

I also have the same issue like aelfwine88.
Another workaround is to put a slash "/" at the end of the url after the first successful login and navigate.
Not very comfortable.

@Lentolo commented on GitHub (Sep 6, 2019): I also have the same issue like aelfwine88. Another workaround is to put a slash "/" at the end of the url after the first successful login and navigate. Not very comfortable.

deekerman commented

Author

Owner

@ghost commented on GitHub (Dec 31, 2019):

Same here. Occurs with FF 71.0 on Macos, with Qbittorrent 4.2.1 (running in linuxserver.io docker). <server-ip>:8080 just shows a white screen.

Accessing <server-ip>:8080/ (note the trailing slash) does work, as well as trying to access <server-ip>:8080 from a private browsing tab.

@ghost commented on GitHub (Dec 31, 2019): Same here. Occurs with FF 71.0 on Macos, with Qbittorrent 4.2.1 (running in linuxserver.io docker). `<server-ip>:8080` just shows a white screen. Accessing `<server-ip>:8080/` (note the trailing slash) _does_ work, as well as trying to access `<server-ip>:8080` from a private browsing tab.

deekerman commented

tbp-nuc_Archive [20-02-04 12-26-48].har.txt

Author

Owner

@TheBestPessimist commented on GitHub (Feb 4, 2020):

Here is a HAR export from firefox 72.0.2 (64-bit) showing the issue

Not sure exactly what is going on, but after trying multiple times to login using tbp-nuc:1414 and being redirected back to the login page (same address tbp-nuc:1414), after i add a / at the end, everything works and i am already logged in: tbp-nuc:1414/.

After logging out (via the webui menu), i can login again normalyy using tbp-nuc:1414, no need for a / at the end.

I'm not sure if this is related to my setup:

i'm using my laptop only to connect via web-ui to my qbittorrent @ home
when @ home i connect via ipv4 only straight through the local lan (wifi router)
when @ remote i connect via ipv4 or ipv6 using zerotier to qbittorrent computer

This is remote pinging:

PS C:\Users\crist> ping -a tbp-nuc

Pinging tbp-nuc.local [fe80::f833:e8b:11f1:95ed%10] with 32 bytes of data:
Reply from fe80::f833:e8b:11f1:95ed%10: time=8ms

[...]

PS C:\Users\crist> ping -a -4 tbp-nuc

Pinging tbp-nuc.local [10.144.141.223] with 32 bytes of data:
Reply from 10.144.141.223: bytes=32 time=6ms TTL=128

I also see that each request, right from the get-go sends a cookie. Not sure if that's related in any way to the issue here.

I have also recorded a video:

open new tab, open qb, login, login again
add / at the end of the url, get magically redirected back to w/o / but in the normal -logged in- state
close tab
open new tab the second time, open qb, i'm presented with the login page
add / at the end of the url without logging in at all, get magically redirected back to w/o / but in the normal -logged in- state

Could this have something to do with some redirections?

@TheBestPessimist commented on GitHub (Feb 4, 2020): Here is a HAR export from firefox 72.0.2 (64-bit) showing the issue [tbp-nuc_Archive [20-02-04 12-26-48].har.txt](https://github.com/qbittorrent/qBittorrent/files/4152692/tbp-nuc_Archive.20-02-04.12-26-48.har.txt) Not sure exactly what is going on, but after trying multiple times to login using `tbp-nuc:1414` and being redirected back to the login page (same address `tbp-nuc:1414`), after i add a `/` at the end, everything works and i am already logged in: `tbp-nuc:1414/`. After logging out (via the webui menu), i can login again normalyy using `tbp-nuc:1414`, no need for a `/` at the end. I'm not sure if this is related to my setup: - i'm using my laptop only to connect via web-ui to my qbittorrent @ home - when @ home i connect via ipv4 only straight through the local lan (wifi router) - when @ remote i connect via ipv4 or ipv6 using zerotier to qbittorrent computer This is remote pinging: ```powershell PS C:\Users\crist> ping -a tbp-nuc Pinging tbp-nuc.local [fe80::f833:e8b:11f1:95ed%10] with 32 bytes of data: Reply from fe80::f833:e8b:11f1:95ed%10: time=8ms [...] PS C:\Users\crist> ping -a -4 tbp-nuc Pinging tbp-nuc.local [10.144.141.223] with 32 bytes of data: Reply from 10.144.141.223: bytes=32 time=6ms TTL=128 ``` I also see that each request, right from the get-go sends a cookie. Not sure if that's related in any way to the issue here. --- I have also recorded a video: ![0000000643](https://user-images.githubusercontent.com/4482210/73737982-493c5a00-474c-11ea-88fb-9d3069bd80c0.gif) - open new tab, open qb, login, login again - add `/` at the end of the url, get magically redirected back to w/o `/` but in the normal -logged in- state - close tab - open new tab the second time, open qb, i'm presented with the login page - add `/` at the end of the url without logging in at all, get magically redirected back to w/o `/` but in the normal -logged in- state Could this have something to do with some redirections?

deekerman commented

Author

Owner

@daddyboo commented on GitHub (Mar 20, 2020):

I have exactly the same problem.
FF 74.0 on Macos, Qbittorrent 4.2.1

@daddyboo commented on GitHub (Mar 20, 2020): I have exactly the same problem. FF 74.0 on Macos, Qbittorrent 4.2.1

deekerman commented

Author

Owner

@0x49D1 commented on GitHub (Apr 8, 2020):

Exactly same issue, but with Firefox Preview. I've tried to contact Firefox team, but they can't reproduce the problem without actual login data... So I think there probably is some problem on qBittorrent's side: the page just refreshes itself after proper credentials' submit action.

@0x49D1 commented on GitHub (Apr 8, 2020): Exactly same issue, but with [Firefox Preview](https://play.google.com/store/apps/details?id=org.mozilla.fenix&hl=en_IE). I've tried to contact Firefox team, but they can't reproduce the problem without actual login data... So I think there probably is some problem on qBittorrent's side: the page just refreshes itself after proper credentials' submit action.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 8, 2020):

The fact that many people seem to be able to get it working by fiddling with the trailing slashes points to a problem in the webserver/reverse proxy configuration. I cannot reproduce this problem with any browser on any system by following any of the setups listed in the wiki (they all use nginx, but there are many people using apache for the same purposes without problems).

@FranciscoPombal commented on GitHub (Apr 8, 2020): The fact that many people seem to be able to get it working by fiddling with the trailing slashes points to a problem in the webserver/reverse proxy configuration. I cannot reproduce this problem with any browser on any system by following any of the setups listed in the wiki (they all use nginx, but there are many people using apache for the same purposes without problems).

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 8, 2020):

following any of the setups listed in the wiki

I installed with:
apt install qbittorrent

And that's all. From there I started the GUI and enabled the build in web-server.

@aelfwine88 commented on GitHub (Apr 8, 2020): > > > following any of the setups listed in the wiki I installed with: apt install qbittorrent And that's all. From there I started the GUI and enabled the build in web-server.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 8, 2020):

@aelfwine88

following any of the setups listed in the wiki

I installed with:
apt install qbittorrent

And that's all. From there I started the GUI and enabled the build in web-server.

Yes, this was one of the simplest configurations that I tested. Could not reproduce.

You mentioned in your case, it only started happening after a while. Could this be related to some extension/configuration in your Firefox you installed/changed in the meantime?

For the record, everything works fine for me wither without extensions or with ublock origin+https everywhere.

@FranciscoPombal commented on GitHub (Apr 8, 2020): @aelfwine88 > > following any of the setups listed in the wiki > > I installed with: > apt install qbittorrent > > And that's all. From there I started the GUI and enabled the build in web-server. Yes, this was one of the simplest configurations that I tested. Could not reproduce. You mentioned in your case, it only started happening after a while. Could this be related to some extension/configuration in your Firefox you installed/changed in the meantime? For the record, everything works fine for me wither without extensions or with ublock origin+https everywhere.

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 8, 2020):

@FranciscoPombal

You mentioned in your case, it only started happening after a while. Could this be related to some extension/configuration in your Firefox you installed/changed in the meantime?

It could be however I tried to disable all extensions also reset FF and it did not helped.

Also as you can see there are several reports since this was first reported with several FF, qBittorrent and OS variants (@facemanak reported that downgrading v4.1.0 solves the problem).

I'm willing to provide you any data or tests that you request except reseting my qBittorrent library of torrents. :)

Btw "Bypass authentication for clients in whitelisted IP subnets" also a viable workaround for me right now.

@aelfwine88 commented on GitHub (Apr 8, 2020): @FranciscoPombal > You mentioned in your case, it only started happening after a while. Could this be related to some extension/configuration in your Firefox you installed/changed in the meantime? It could be however I tried to disable all extensions also reset FF and it did not helped. Also as you can see there are several reports since this was first reported with several FF, qBittorrent and OS variants (@facemanak reported that downgrading v4.1.0 solves the problem). I'm willing to provide you any data or tests that you request except reseting my qBittorrent library of torrents. :) Btw "Bypass authentication for clients in whitelisted IP subnets" also a viable workaround for me right now.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 8, 2020):

@aelfwine88
Thank you for your willingness to help.

Also as you can see there are several reports since this was first reported with several FF, qBittorrent and OS variants (@facemanak reported that downgrading v4.1.0 solves the problem).

They also mention that reinstalling FF temporarily fixed the problem. There must be something happening in between. Could it be some kind of firewall or antivirus silently intervening by adding a rule or something? Can you try disabling those temporarily and testing again?

I'm willing to provide you any data or tests that you request except reseting my qBittorrent library of torrents. :)
Btw "Bypass authentication for clients in whitelisted IP subnets" also a viable workaround for me right now.

Interesting. In addition to the testing above, if you could provide a Wireshark capture of the HTTP (not HTTPS) traffic both at the client and the server, that would be great. Try to capture the following sequence: navigating to the qBittorrent WebUI page; attempting to log in twice. Be sure to configure the WebUI password to something you don't use before doing this.

@FranciscoPombal commented on GitHub (Apr 8, 2020): @aelfwine88 Thank you for your willingness to help. > Also as you can see there are several reports since this was first reported with several FF, qBittorrent and OS variants (@facemanak reported that downgrading v4.1.0 solves the problem). They also mention that reinstalling FF temporarily fixed the problem. There must be something happening in between. Could it be some kind of firewall or antivirus silently intervening by adding a rule or something? Can you try disabling those temporarily and testing again? >I'm willing to provide you any data or tests that you request except reseting my qBittorrent library of torrents. :) >Btw "Bypass authentication for clients in whitelisted IP subnets" also a viable workaround for me right now. Interesting. In addition to the testing above, if you could provide a Wireshark capture of the HTTP (not HTTPS) traffic both at the client and the server, that would be great. Try to capture the following sequence: navigating to the qBittorrent WebUI page; attempting to log in twice. Be sure to configure the WebUI password to something you don't use before doing this.

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

I tried and I was not able to reproduce the problem with HTTP, only with HTTPS enabled. This however does not necessary mean that it happens only with HTTPS enabled since the bug is pretty tricky: sometimes after a successful login with one of the workarounds it just start to work as it intended and you can do whatever you want (delete cookies, browser cache, restart) still cannot reproduce the issue. But then again it returns after a short while. I fiddled with it today testing Wireshark captures and it consistently produced the error. Then when I had a capture that I was satisfied with I realized that I forgot to pack the TLS key files with the capture so I wanted to create one more capture and the error just disappeared... It take me a good 10 minutes of random cache cleaning and restarting till the problem started to occuring again. So in the end I have a client side HTTPS capture for you with the TLS key to decrypt the traffic as well. Can you contact me on some private channel where I can share them whit you?

@aelfwine88 commented on GitHub (Apr 9, 2020): I tried and I was not able to reproduce the problem with HTTP, only with HTTPS enabled. This however does not necessary mean that it happens only with HTTPS enabled since the bug is pretty tricky: sometimes after a successful login with one of the workarounds it just start to work as it intended and you can do whatever you want (delete cookies, browser cache, restart) still cannot reproduce the issue. But then again it returns after a short while. I fiddled with it today testing Wireshark captures and it consistently produced the error. Then when I had a capture that I was satisfied with I realized that I forgot to pack the TLS key files with the capture so I wanted to create one more capture and the error just disappeared... It take me a good 10 minutes of random cache cleaning and restarting till the problem started to occuring again. So in the end I have a client side HTTPS capture for you with the TLS key to decrypt the traffic as well. Can you contact me on some private channel where I can share them whit you?

deekerman commented

github.com/qbittorrent/qBittorrent@43e5e242ff/src/webui/webapplication.cpp (L540)

Author

Owner

@Piccirello commented on GitHub (Apr 9, 2020):

I suspect the reason this is occurring is because of this line

If I curl the web ui, you can see the set-cookie header using a path of /, even when the URL doesn't

 $ curl -I -k https://127.0.0.1:8090
HTTP/1.1 200 OK
cache-control: no-store
connection: keep-alive
content-length: 19911
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests;
content-type: text/html
date: Thu, 09 Apr 2020 09:54:38 GMT
referrer-policy: same-origin
set-cookie: SID=REDACTED; secure; HttpOnly; path=/; SameSite=Strict
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

MDN says this about the Set-Cookie header:

Path=<path-value> Optional
A path that must exist in the requested URL, or the browser won't send the Cookie header.
The forward slash (/) character is interpreted as a directory separator...

With qBittorrent 4.2.3 and Firefox 75.0 on macOS 10.14.6 I wasn't able to reproduce over HTTP or HTTPS.

For anyone using a reverse proxy: ensure your proxy_pass (nginx) or ProxyPass (apache) statement ends with a trailing slash /.

nginx:

proxy_pass http://127.0.0.1:8080/;

apache:

ProxyPass http://127.0.0.1:8080/

@Piccirello commented on GitHub (Apr 9, 2020): I suspect the reason this is occurring is because of this line https://github.com/qbittorrent/qBittorrent/blob/43e5e242ff31da009c67e4365925e11604131980/src/webui/webapplication.cpp#L540 If I curl the web ui, you can see the `set-cookie` header using a path of `/`, even when the URL doesn't ```sh $ curl -I -k https://127.0.0.1:8090 HTTP/1.1 200 OK cache-control: no-store connection: keep-alive content-length: 19911 content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests; content-type: text/html date: Thu, 09 Apr 2020 09:54:38 GMT referrer-policy: same-origin set-cookie: SID=REDACTED; secure; HttpOnly; path=/; SameSite=Strict x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block ``` MDN says [this](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Directives) about the `Set-Cookie` header: > `Path=<path-value>` `Optional` > A path that must exist in the requested URL, or the browser won't send the `Cookie` header. > The forward slash (`/`) character is interpreted as a directory separator... With qBittorrent 4.2.3 and Firefox 75.0 on macOS 10.14.6 I wasn't able to reproduce over HTTP or HTTPS. **For anyone using a reverse proxy**: ensure your `proxy_pass` (nginx) or `ProxyPass` (apache) statement ends with a trailing slash `/`. nginx: ```nginx proxy_pass http://127.0.0.1:8080/; ``` apache: ```apache ProxyPass http://127.0.0.1:8080/ ```

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

With qBittorrent 4.2.3 and Firefox 75.0 on macOS 10.14.6 I wasn't able to reproduce over HTTP or HTTPS.

I have qBittorrent 4.2.3 and Firefox 75.0 and just had the problem from Windows 10.

Also there is this two workarounds along with the "insert / to the end of the url" that might interest you:

It works perfectly from FF incognito mode from same machine (without the ending /).
It works if I access the login URL from a redirection. Like adding this to a site/local html:
<a href="https://192.168.1.1">qBittorrent site</a>

The link in last workaround does not have a / in the end still working.

@aelfwine88 commented on GitHub (Apr 9, 2020): > With qBittorrent 4.2.3 and Firefox 75.0 on macOS 10.14.6 I wasn't able to reproduce over HTTP or HTTPS. I have qBittorrent 4.2.3 and Firefox 75.0 and just had the problem from Windows 10. Also there is this two workarounds along with the "insert / to the end of the url" that might interest you: - It works perfectly from FF incognito mode from same machine (without the ending /). - It works if I access the login URL from a redirection. Like adding this to a site/local html: `<a href="https://192.168.1.1">qBittorrent site</a>` The link in last workaround does not have a / in the end still working.

deekerman commented

Author

Owner

@Piccirello commented on GitHub (Apr 9, 2020):

I don't seem to be able to navigate to urls in Firefox without a trailing slash being appended. This is both in regular browsing and a fresh incognito session. In case it's relevant I've also set browser.urlbar.trimURLs to false in about:config.

@Piccirello commented on GitHub (Apr 9, 2020): I don't seem to be able to navigate to urls in Firefox without a trailing slash being appended. This is both in regular browsing and a fresh incognito session. In case it's relevant I've also set `browser.urlbar.trimURLs` to false in `about:config`. <img width="495" alt="Screen Shot 2020-04-09 at 3 14 37 AM" src="https://user-images.githubusercontent.com/8296030/78884768-51489c80-7a10-11ea-93c8-efa2322e2cff.png"> <img width="675" alt="Screen Shot 2020-04-09 at 3 20 20 AM" src="https://user-images.githubusercontent.com/8296030/78885243-18f58e00-7a11-11ea-8f47-db46069aa112.png">

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

This is how it looks like for me (Wireshark from client, 1st failed attempt):

POST /api/v2/auth/login HTTP/1.1
Host: myhostname.local:8765
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: */*
Accept-Language: en-US,hu;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://myhostname.local:8765/
Content-type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 37
Origin: https://myhostname.local:8765
Connection: keep-alive

username=wireshark&password=wiresharkHTTP/1.1 200 OK
connection: keep-alive
content-length: 3
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests;
content-type: text/plain
date: Thu, 09 Apr 2020 08:24:29 GMT
referrer-policy: same-origin
set-cookie: SID=RANDOMSTRING; secure; HttpOnly; path=/; SameSite=Strict
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

Ok.

2nd failed attempt is the exact same except it now uses the Cookie: SID=RANDOMSTRING in the first part.

@aelfwine88 commented on GitHub (Apr 9, 2020): This is how it looks like for me (Wireshark from client, 1st failed attempt): ``` POST /api/v2/auth/login HTTP/1.1 Host: myhostname.local:8765 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Accept: */* Accept-Language: en-US,hu;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br Referer: https://myhostname.local:8765/ Content-type: application/x-www-form-urlencoded; charset=utf-8 Content-Length: 37 Origin: https://myhostname.local:8765 Connection: keep-alive username=wireshark&password=wiresharkHTTP/1.1 200 OK connection: keep-alive content-length: 3 content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests; content-type: text/plain date: Thu, 09 Apr 2020 08:24:29 GMT referrer-policy: same-origin set-cookie: SID=RANDOMSTRING; secure; HttpOnly; path=/; SameSite=Strict x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block Ok. ``` 2nd failed attempt is the exact same except it now uses the `Cookie: SID=RANDOMSTRING` in the first part.

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

And this happens when I add the "/":

GET / HTTP/1.1
Host: myhostname.local:8765
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,hu;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
cache-control: no-store
connection: keep-alive
content-encoding: gzip
content-length: 580
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests;
content-type: text/html
date: Thu, 09 Apr 2020 08:24:39 GMT
referrer-policy: same-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

...........U]o.0.}.........^.p2..I.IL.
.	9.]b...v.....I.V.....^...{.O.v.......OPy%..k/ ..........Hg.~L...W.:.	Y.\..%@.M/..t.^xo.E...f...h..().
,....h.~[c../...$PY....u+..:.Q.y=.@./...|...	.so.v..S..o%.
.....<...XCH.)....b..W>..=.6....1}..@.H.zX.....C...:...........Q..p?...g,3..H.."!CBFz.E..o......FX,...4....5.$..tg,.
{..7po.
jkj.r..X<........>jb.y....a..@..sa.F.x:.Pe..i.p...q..MGUi(;.D...%..O....e...@x.+..j..m.vM.D."^.Z.e.>....mW..g..."Z.g(.SJH..j....>b..NYf.B.G....<M:.;.h..9o..M....u.....B..
.+Hz.G.*d....gQ.>?..7.4....5.).:......&.\.lB.DuF[s.v-Zk.O.J2......F...>&.....S]...GET /css/login.css?v=o0tba1 HTTP/1.1
Host: myhostname.local:8765
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-US,hu;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://myhostname.local:8765/
Connection: keep-alive
Cookie: SID=RANDOMSTRING
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
cache-control: private, max-age=43200
connection: keep-alive
content-length: 510
content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests;
content-type: text/css
date: Thu, 09 Apr 2020 08:24:39 GMT
referrer-policy: same-origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

body {
    margin: 0;
    text-align: left;
    font-family: Arial, Helvetica, sans-serif;
    font-size: 12px;
    line-height: 18px;
    color: #555;
}
...keeps loading the site...

@aelfwine88 commented on GitHub (Apr 9, 2020): And this happens when I add the "/": ```` GET / HTTP/1.1 Host: myhostname.local:8765 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,hu;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br Connection: keep-alive Upgrade-Insecure-Requests: 1 Pragma: no-cache Cache-Control: no-cache HTTP/1.1 200 OK cache-control: no-store connection: keep-alive content-encoding: gzip content-length: 580 content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests; content-type: text/html date: Thu, 09 Apr 2020 08:24:39 GMT referrer-policy: same-origin x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block ...........U]o.0.}.........^.p2..I.IL. . 9.]b...v.....I.V.....^...{.O.v.......OPy%..k/ ..........Hg.~L...W.:. Y.\..%@.M/..t.^xo.E...f...h..(). ,....h.~[c../...$PY....u+..:.Q.y=.@./...|... .so.v..S..o%. .....<...XCH.)....b..W>..=.6....1}..@.H.zX.....C...:...........Q..p?...g,3..H.."!CBFz.E..o......FX,...4....5.$..tg,. {..7po. jkj.r..X<........>jb.y....a..@..sa.F.x:.Pe..i.p...q..MGUi(;.D...%..O....e...@x.+..j..m.vM.D."^.Z.e.>....mW..g..."Z.g(.SJH..j....>b..NYf.B.G....<M:.;.h..9o..M....u.....B.. .+Hz.G.*d....gQ.>?..7.4....5.).:......&.\.lB.DuF[s.v-Zk.O.J2......F...>&.....S]...GET /css/login.css?v=o0tba1 HTTP/1.1 Host: myhostname.local:8765 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Accept: text/css,*/*;q=0.1 Accept-Language: en-US,hu;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br Referer: https://myhostname.local:8765/ Connection: keep-alive Cookie: SID=RANDOMSTRING Pragma: no-cache Cache-Control: no-cache HTTP/1.1 200 OK cache-control: private, max-age=43200 connection: keep-alive content-length: 510 content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests; content-type: text/css date: Thu, 09 Apr 2020 08:24:39 GMT referrer-policy: same-origin x-content-type-options: nosniff x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block body { margin: 0; text-align: left; font-family: Arial, Helvetica, sans-serif; font-size: 12px; line-height: 18px; color: #555; } ...keeps loading the site... ````

deekerman commented

Author

Owner

@Piccirello commented on GitHub (Apr 9, 2020):

It works if I access the login URL from a redirection. Like adding this to a site/local html:
<a href="https://192.168.1.1">qBittorrent site</a>

The link in last workaround does not have a / in the end still working.

I create a static html file

 $ cat qbit.html
<a href="https://127.0.0.1:8090">qBittorrent site</a>

I then opened it in Firefox. You can see in the screenshot that the URL in the DOM does not have a trailing slash. At the same time, in the lower left corner the status bar is displaying the URL that the window will navigate to if clicked (my cursor was hovering over the anchor element). The status bar URL miraculously has a trailing slash. I don't know if this is OS-specific, but it's pretty interesting behavior. Anyway, this is just a tangent about why I may not be able to reproduce the issue.

This is how it looks like for me (Wireshark from client, 1st failed attempt):

POST /api/v2/auth/login HTTP/1.1
Host: myhostname.local:8765
...
Referer: https://myhostname.local:8765/
...
referrer-policy: same-origin
set-cookie: SID=RANDOMSTRING; secure; HttpOnly; path=/; SameSite=Strict

Notice the trailing slash in the Referer header.

@Piccirello commented on GitHub (Apr 9, 2020): > * It works if I access the login URL from a redirection. Like adding this to a site/local html: > `<a href="https://192.168.1.1">qBittorrent site</a>` > > The link in last workaround does not have a / in the end still working. I create a static html file ```sh $ cat qbit.html <a href="https://127.0.0.1:8090">qBittorrent site</a> ``` I then opened it in Firefox. You can see in the screenshot that the URL in the DOM does not have a trailing slash. At the same time, in the lower left corner the status bar is displaying the URL that the window will navigate to if clicked (my cursor was hovering over the anchor element). The status bar URL miraculously has a trailing slash. I don't know if this is OS-specific, but it's pretty interesting behavior. Anyway, this is just a tangent about why I may not be able to reproduce the issue. <img width="719" alt="Screen Shot 2020-04-09 at 3 29 11 AM" src="https://user-images.githubusercontent.com/8296030/78886121-9077ed00-7a12-11ea-8471-b13f253f0528.png"> > This is how it looks like for me (Wireshark from client, 1st failed attempt): > ``` > POST /api/v2/auth/login HTTP/1.1 > Host: myhostname.local:8765 > ... > Referer: https://myhostname.local:8765/ > ... > referrer-policy: same-origin > set-cookie: SID=RANDOMSTRING; secure; HttpOnly; path=/; SameSite=Strict > ``` Notice the trailing slash in the `Referer` header.

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

I don't understand HTTP that well. :) I just try to provide information to you guys.

Origin: https://myhostname.local:8765
...
Referer: https://myhostname.local:8765/
...
referrer-policy: same-origin

That being said I don't know what is referrer policy is, but "same-origin" while Origin is without the trailing slash seems suspicious to me.

@aelfwine88 commented on GitHub (Apr 9, 2020): I don't understand HTTP that well. :) I just try to provide information to you guys. ``` Origin: https://myhostname.local:8765 ... Referer: https://myhostname.local:8765/ ... referrer-policy: same-origin ``` That being said I don't know what is referrer policy is, but "same-origin" while Origin is without the trailing slash seems suspicious to me.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 9, 2020):

@aelfwine88 can you post your logs please (make sure to redact any sensitive data)? Don't you get some error like WebUI: Referrer header & Target origin mismatch...?

@FranciscoPombal commented on GitHub (Apr 9, 2020): @aelfwine88 can you post your logs please (make sure to redact any sensitive data)? Don't you get some error like `WebUI: Referrer header & Target origin mismatch...`?

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

@FranciscoPombal I managed to redact most of the sensitive data but I do not know how to redact my original hostname and port from the wireshark log files. This is why I asked for a private line to you where I can share the logs with only you guys.
Also I did not found any error messages following through the TLS streams, but again, I am far from an expert on the subject.

@aelfwine88 commented on GitHub (Apr 9, 2020): @FranciscoPombal I managed to redact most of the sensitive data but I do not know how to redact my original hostname and port from the wireshark log files. This is why I asked for a private line to you where I can share the logs with only you guys. Also I did not found any error messages following through the TLS streams, but again, I am far from an expert on the subject.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 9, 2020):

@aelfwine88

@FranciscoPombal I managed to redact most of the sensitive data but I do not know how to redact my original hostname and port from the wireshark log files. This is why I asked for a private line to you where I can share the logs with only you guys.
Also I did not found any error messages following through the TLS streams, but again, I am far from an expert on the subject.

I meant the qBittorrent log files, we can start with that.

@FranciscoPombal commented on GitHub (Apr 9, 2020): @aelfwine88 > @FranciscoPombal I managed to redact most of the sensitive data but I do not know how to redact my original hostname and port from the wireshark log files. This is why I asked for a private line to you where I can share the logs with only you guys. > Also I did not found any error messages following through the TLS streams, but again, I am far from an expert on the subject. I meant the qBittorrent log files, we can start with that.

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (Apr 9, 2020):

I see. There is only this much in there (/.local/share/data/qBittorrent/logs/qbittorrent.log):

(W) 2020-04-09T15:14:45 -  is not a valid IP address and was rejected while applying the list of banned addresses.
(N) 2020-04-09T15:14:45 - Web UI: HTTPS setup successful
(N) 2020-04-09T15:14:45 - Web UI: Now listening on IP: *, port: 8443
(N) 2020-04-09T15:14:45 - Options were saved successfully.
(W) 2020-04-09T15:17:19 -  is not a valid IP address and was rejected while applying the list of banned addresses.
(N) 2020-04-09T15:17:19 - Web UI: HTTPS setup successful
(N) 2020-04-09T15:17:19 - Web UI: Now listening on IP: *, port: 8443
(N) 2020-04-09T15:17:19 - Options were saved successfully.

This is turning off whitelisted IP bypass (15:14:45), trying to log on 5-6 times (nothing appears) then adding a / and log in successfully (15:17:19).
This is pretty much all there is in the log. Occasionally there is this line, when IP bypass is enabled:
WebAPI login success. IP: ::ffff:192.168.1.10

@aelfwine88 commented on GitHub (Apr 9, 2020): I see. There is only this much in there (/.local/share/data/qBittorrent/logs/qbittorrent.log): ``` (W) 2020-04-09T15:14:45 - is not a valid IP address and was rejected while applying the list of banned addresses. (N) 2020-04-09T15:14:45 - Web UI: HTTPS setup successful (N) 2020-04-09T15:14:45 - Web UI: Now listening on IP: *, port: 8443 (N) 2020-04-09T15:14:45 - Options were saved successfully. (W) 2020-04-09T15:17:19 - is not a valid IP address and was rejected while applying the list of banned addresses. (N) 2020-04-09T15:17:19 - Web UI: HTTPS setup successful (N) 2020-04-09T15:17:19 - Web UI: Now listening on IP: *, port: 8443 (N) 2020-04-09T15:17:19 - Options were saved successfully. ``` This is turning off whitelisted IP bypass (15:14:45), trying to log on 5-6 times (nothing appears) then adding a / and log in successfully (15:17:19). This is pretty much all there is in the log. Occasionally there is this line, when IP bypass is enabled: `WebAPI login success. IP: ::ffff:192.168.1.10`

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 9, 2020):

This is why I asked for a private line to you where I can share the logs with only you guys.

Since the qBittorrent logs don't show anything useful, you can send the wireshark capture to pombal (dot) francisco (at) (google's mail service dot com). I'll give it a shot.

@FranciscoPombal commented on GitHub (Apr 9, 2020): > This is why I asked for a private line to you where I can share the logs with only you guys. Since the qBittorrent logs don't show anything useful, you can send the wireshark capture to `pombal` (dot) `francisco` (at) (google's mail service dot com). I'll give it a shot.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Apr 13, 2020):

@aelfwine88 Hey, I tried to analyze the files you sent me, but it seems the tls secrets file did not contain all the necessary keys. Most notably, the actual JSON payload of the sync/maindata request was not decrypted. I even tried embedding the secrets in the pcapng file and opening that, but (predictably) got the same result (editcap --inject-secrets tls,sslkeylog.log qbt_login.pcapng qbt_login_dsb.pcapng).

You can either try to provide the full decryption keys or try to reproduce the problem with HTTP (if possible), as it simplifies the capture and analysis.

@FranciscoPombal commented on GitHub (Apr 13, 2020): @aelfwine88 Hey, I tried to analyze the files you sent me, but it seems the tls secrets file did not contain all the necessary keys. Most notably, the actual JSON payload of the sync/maindata request was not decrypted. I even tried embedding the secrets in the pcapng file and opening that, but (predictably) got the same result (`editcap --inject-secrets tls,sslkeylog.log qbt_login.pcapng qbt_login_dsb.pcapng`). You can either try to provide the full decryption keys or try to reproduce the problem with HTTP (if possible), as it simplifies the capture and analysis.

deekerman commented

Author

Owner

@Piccirello commented on GitHub (May 1, 2020):

I'm finally able to reliably reproduce this issue. In my case, it requires a specific setup:

first-party JavaScript must be blocked via uMatrix (or similar extenion)
uMatrix option Spoof <noscript> tags when 1st-party scripts are blocked must be unchecked

With this setup, the JavaScript required for the form cannot run. What's worse, the <noscript> tags won't "run" because JavaScript is technically enabled. This leads to a form erroneously being displayed that defaults to POSTing to the current url (/) rather than /api/v2/auth/login.

The only real bug here was a belief that <noscript> was simple. The broken form itself isn't a bug because it's never intended for the user to be able to see it. Thankfully the solution is simple: control the display of the form via JavaScript, rather than solely relying on <noscript>.

It's more than likely that other people experiencing this issue aren't using my exact setup. Nevertheless, one sure sign that you're experiencing this same bug is if the username field isn't auto-focused on page load. This focus event occurs on DOMContentLoaded, and without JavaScript it won't fire. Another indicator is if the login <form> POSTs to /.

Can anyone else experiencing this issue confirm that the username field isn't being auto-focused AND that the POST request goes to / rather than /api/v2/auth/login?

@Piccirello commented on GitHub (May 1, 2020): I'm finally able to reliably reproduce this issue. In my case, it requires a specific setup: 1) first-party JavaScript must be blocked via uMatrix (or similar extenion) 2) uMatrix option `Spoof <noscript> tags when 1st-party scripts are blocked` must be unchecked With this setup, the JavaScript required for the form cannot run. What's worse, the `<noscript>` tags won't "run" because JavaScript is technically enabled. This leads to a form erroneously being displayed that defaults to POSTing to the current url (`/`) rather than `/api/v2/auth/login`. The only real bug here was a belief that `<noscript>` was simple. The broken form itself isn't a bug because it's never intended for the user to be able to see it. Thankfully the solution is simple: control the display of the form via JavaScript, rather than solely relying on `<noscript>`. It's more than likely that other people experiencing this issue aren't using my exact setup. Nevertheless, one sure sign that you're experiencing this same bug is if the username field isn't auto-focused on page load. This focus event occurs on `DOMContentLoaded`, and without JavaScript it won't fire. Another indicator is if the login `<form>` POSTs to `/`. **Can anyone else experiencing this issue confirm that the username field isn't being auto-focused AND that the POST request goes to `/` rather than `/api/v2/auth/login`?**

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (May 2, 2020):

I have it autofocused on page load, even the cached username list pops open automatically (since a few FF updates ago). Also post request goes to: https://xxxx:yyyy/api/v2/auth/login

@aelfwine88 commented on GitHub (May 2, 2020): I have it autofocused on page load, even the cached username list pops open automatically (since a few FF updates ago). Also post request goes to: https://xxxx:yyyy/api/v2/auth/login

deekerman commented

Author

Owner

@aelfwine88 commented on GitHub (May 2, 2020):

Hello,

Managed to create a capture without https.

I did the following in this:

Refresh the page with FQDN
Tried to log in but failed
Tried to log in but failed
Tried to use "/" to produce a valid login which did not worked somehow
Went to my https page where is a redirect link to
https://192.168.1.1:8443
Clicked the redirect
Modified the URL in my browser to http://192.168.1.1:8443
Valid login occurred

I hope this helps.
Regards,
Eriol

On Mon, Apr 13, 2020 at 2:19 PM Francisco Pombal notifications@github.com
wrote:

@aelfwine88 https://github.com/aelfwine88 Hey, I tried to analyze the
files you sent me, but it seems the tls secrets file did not contain all
the necessary keys. Most notably, the actual JSON payload of the
sync/maindata request was not decrypted. I even tried embedding the secrets
in the pcapng file and opening that, but (predictably) got the same result (editcap
--inject-secrets tls,sslkeylog.log qbt_login.pcapng qbt_login_dsb.pcapng).

You can either try to provide the full decryption keys or try to reproduce
the problem with HTTP (if possible), as it simplifies the capture and
analysis.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/10405#issuecomment-612875743,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBPMPDUH56ITWNZMSYCRODRML7ODANCNFSM4HAWLLOA
.

@aelfwine88 commented on GitHub (May 2, 2020): Hello, Managed to create a capture without https. I did the following in this: 1. Refresh the page with FQDN 2. Tried to log in but failed 3. Tried to log in but failed 4. Tried to use "/" to produce a valid login which did not worked somehow 5. Went to my https page where is a redirect link to https://192.168.1.1:8443 6. Clicked the redirect 7. Modified the URL in my browser to http://192.168.1.1:8443 8. Valid login occurred I hope this helps. Regards, Eriol On Mon, Apr 13, 2020 at 2:19 PM Francisco Pombal <notifications@github.com> wrote: > @aelfwine88 <https://github.com/aelfwine88> Hey, I tried to analyze the > files you sent me, but it seems the tls secrets file did not contain all > the necessary keys. Most notably, the actual JSON payload of the > sync/maindata request was not decrypted. I even tried embedding the secrets > in the pcapng file and opening that, but (predictably) got the same result (editcap > --inject-secrets tls,sslkeylog.log qbt_login.pcapng qbt_login_dsb.pcapng). > > You can either try to provide the full decryption keys or try to reproduce > the problem with HTTP (if possible), as it simplifies the capture and > analysis. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/qbittorrent/qBittorrent/issues/10405#issuecomment-612875743>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABBPMPDUH56ITWNZMSYCRODRML7ODANCNFSM4HAWLLOA> > . >

deekerman commented

Author

Owner

@xavier2k6 commented on GitHub (Mar 1, 2021):

@Piccirello @FranciscoPombal Is this still an issue or can this be closed?

@xavier2k6 commented on GitHub (Mar 1, 2021): @Piccirello @FranciscoPombal Is this still an issue or can this be closed?

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Mar 1, 2021):

@xavier2k6 Not sure, but since they have reproduced in https://github.com/qbittorrent/qBittorrent/issues/10405#issuecomment-622358837, I think this should be left open for now.

@FranciscoPombal commented on GitHub (Mar 1, 2021): @xavier2k6 Not sure, but since they have reproduced in https://github.com/qbittorrent/qBittorrent/issues/10405#issuecomment-622358837, I think this should be left open for now.

deekerman commented

Author

Owner

@Themis3000 commented on GitHub (Jul 10, 2021):

@Piccirello @FranciscoPombal Is this still an issue or can this be closed?

This is still an issue, I just experienced it on the latest stable release of firefox (89.0.2).

@Themis3000 commented on GitHub (Jul 10, 2021): > > > @Piccirello @FranciscoPombal Is this still an issue or can this be closed? This is still an issue, I just experienced it on the latest stable release of firefox (89.0.2).

deekerman commented

Author

Owner

@dejjem commented on GitHub (Aug 3, 2021):

Latest Firefox, trailing slash solves it for me... Ex: http://192.168.1.1:8484/

Like this http://192.168.1.1:8484 it doesn't work except in incognito...

@dejjem commented on GitHub (Aug 3, 2021): Latest Firefox, trailing slash solves it for me... Ex: http://192.168.1.1:8484/ Like this http://192.168.1.1:8484 it doesn't work except in incognito...

deekerman commented

Author

Owner

@brzzdev commented on GitHub (Mar 18, 2022):

Yeah I'm still getting this

@brzzdev commented on GitHub (Mar 18, 2022): Yeah I'm still getting this

deekerman commented

Author

Owner

@Themis3000 commented on GitHub (Mar 18, 2022):

On qbittorrent 4.4.1 this no longer is an issue for me, no matter if there's a trailing slash or not, and no matter if I'm in incognito.

What version of firefox and qbittorrent are you using @PaulDoesDev ?

@Themis3000 commented on GitHub (Mar 18, 2022): On qbittorrent 4.4.1 this no longer is an issue for me, no matter if there's a trailing slash or not, and no matter if I'm in incognito. What version of firefox and qbittorrent are you using @PaulDoesDev ?

deekerman commented

Author

Owner

@brzzdev commented on GitHub (Mar 19, 2022):

@Themis3000 Latest 4.4.1 from this docker image on a Synology NAS.
Latest 98.0.1 Firefox on macOS 12.3.

My workaround is just to use the bypass auth feature.

@brzzdev commented on GitHub (Mar 19, 2022): @Themis3000 Latest 4.4.1 from [this](https://hub.docker.com/r/linuxserver/qbittorrent) docker image on a Synology NAS. Latest 98.0.1 Firefox on macOS 12.3. My workaround is just to use the bypass auth feature.

deekerman commented

Author

Owner

@Generator commented on GitHub (May 5, 2022):

Having the same issue if the open when URL from other service (Portainer, Flame).
Ex: add app (qbittorrent) to Flame, click on the link, login doesn't work.
If enter the same qbittorrent URL on address bar or modify the url (add/remove '/') , login works

The same should happen with similar services like Homer, Heimdall, SUI...

qBittorrent 4.4.2

@Generator commented on GitHub (May 5, 2022): Having the same issue if the open when URL from other service (Portainer, [Flame](https://github.com/pawelmalak/flame)). Ex: add app (qbittorrent) to Flame, click on the link, login doesn't work. If enter the same qbittorrent URL on address bar or modify the url (add/remove '/') , login works The same should happen with similar services like Homer, Heimdall, SUI... qBittorrent 4.4.2

deekerman commented

Author

Owner

@Themis3000 commented on GitHub (Aug 23, 2022):

@PriitUring no, latest qbittorrent and firefox no longer has this issue for me fortunately

@Themis3000 commented on GitHub (Aug 23, 2022): @PriitUring no, latest qbittorrent and firefox no longer has this issue for me fortunately

deekerman commented

Author

Owner

@Bits2n0ne commented on GitHub (Jan 30, 2023):

I ran into the same problem. Im using FF 109.0 (64-bit) for Arch with qBit v4.5.0 from Docker. Everytime i entered the default username/password which is admin/adminadmin, the page just refreshes. The workaround using "/" at the end of the given url from 0.0.0.0:8080 to 0.0.0.0:8080/ fixed the situation. Another workaround i used is to use another browser which i have tested using brave and it worked flawlessly. After managing to enter Qbit, i changed the username and password. Finally, i managed to solve the problem by using the url http://localhost:8080 and it worked flawlessly just like Brave.

@Bits2n0ne commented on GitHub (Jan 30, 2023): I ran into the same problem. Im using FF 109.0 (64-bit) for Arch with qBit v4.5.0 from Docker. Everytime i entered the default username/password which is admin/adminadmin, the page just refreshes. The workaround using "/" at the end of the given url from 0.0.0.0:8080 to 0.0.0.0:8080/ fixed the situation. Another workaround i used is to use another browser which i have tested using brave and it worked flawlessly. After managing to enter Qbit, i changed the username and password. Finally, i managed to solve the problem by using the url http://localhost:8080 and it worked flawlessly just like Brave.

deekerman commented

Author

Owner

@luzpaz commented on GitHub (Sep 4, 2023):

@Bits2n0ne is this still the case for v4.5.4 ?

@luzpaz commented on GitHub (Sep 4, 2023): @Bits2n0ne is this still the case for v4.5.4 ?

deekerman commented

Author

Owner

@luzpaz commented on GitHub (Oct 24, 2023):

@Bits2n0ne ping

@luzpaz commented on GitHub (Oct 24, 2023): @Bits2n0ne ping

deekerman commented

Author

Owner

@johnhelt commented on GitHub (Nov 6, 2023):

I ran into the same problem. Im using FF 109.0 (64-bit) for Arch with qBit v4.5.0 from Docker. Everytime i entered the default username/password which is admin/adminadmin, the page just refreshes. The workaround using "/" at the end of the given url from 0.0.0.0:8080 to 0.0.0.0:8080/ fixed the situation. Another workaround i used is to use another browser which i have tested using brave and it worked flawlessly. After managing to enter Qbit, i changed the username and password. Finally, i managed to solve the problem by using the url http://localhost:8080 and it worked flawlessly just like Brave.

I am seeing this on 4.5.4 running in docker, and firefox 119.0 (64bit) running on win 11. Workaround as @Bits2n0ne mentioned by adding / after the webui port.

@johnhelt commented on GitHub (Nov 6, 2023): > I ran into the same problem. Im using FF 109.0 (64-bit) for Arch with qBit v4.5.0 from Docker. Everytime i entered the default username/password which is admin/adminadmin, the page just refreshes. The workaround using "/" at the end of the given url from 0.0.0.0:8080 to 0.0.0.0:8080/ fixed the situation. Another workaround i used is to use another browser which i have tested using brave and it worked flawlessly. After managing to enter Qbit, i changed the username and password. Finally, i managed to solve the problem by using the url http://localhost:8080 and it worked flawlessly just like Brave. I am seeing this on 4.5.4 running in docker, and firefox 119.0 (64bit) running on win 11. Workaround as @Bits2n0ne mentioned by adding / after the webui port.

deekerman commented

Author

Owner

@ctag commented on GitHub (Dec 23, 2023):

I believe I'm running into the same issue with qBittorrent v4.6.2 and firefox 120.0.1. Logging in just takes me back to the log in screen.
Removing the trailing slash then loads the full UI for me.

@ctag commented on GitHub (Dec 23, 2023): I believe I'm running into the same issue with qBittorrent v4.6.2 and firefox 120.0.1. Logging in just takes me back to the log in screen. *Removing* the trailing slash then loads the full UI for me.

deekerman commented

Author

Owner

@Tschi02 commented on GitHub (Jan 20, 2024):

Wow! This issue persist still almost 5 years later with the latest firefox and the latest qbittorrent 😮 At least the workaround with the extra slash still works, too

@Tschi02 commented on GitHub (Jan 20, 2024): Wow! This issue persist still almost 5 years later with the latest firefox and the latest qbittorrent 😮 At least the workaround with the extra slash still works, too

deekerman commented

Author

Owner

@ColderCoder commented on GitHub (Feb 17, 2024):

same here. WIndows 10 x64, Firefox 122.0.1 x64, qbittorrent 4.3.9
ctrl+f5 / clear cookie won't help, but manually appending a / to the url does the job

@ColderCoder commented on GitHub (Feb 17, 2024): same here. WIndows 10 x64, Firefox 122.0.1 x64, qbittorrent 4.3.9 ctrl+f5 / clear cookie won't help, but manually appending a `/` to the url does the job

deekerman commented

Author

Owner

@xavier2k6 commented on GitHub (May 6, 2024):

This appears to be only affecting Firefox, can this still be re-produced without the workaround using qBittorrent 4.6.4 & Firefox 125?

@xavier2k6 commented on GitHub (May 6, 2024): This appears to be only affecting Firefox, can this still be re-produced without the workaround using qBittorrent 4.6.4 & Firefox 125?

deekerman commented

Author

Owner

@GeoffreyCoulaud commented on GitHub (May 14, 2024):

@xavier2k6 I can confirm that the issue can be reproduced in FF 125.0.3 with qBittorrent 4.6.4. This thread actually saved my sanity.

@GeoffreyCoulaud commented on GitHub (May 14, 2024): @xavier2k6 I can confirm that the issue can be reproduced in FF 125.0.3 with qBittorrent 4.6.4. This thread actually saved my sanity.

deekerman commented

Author

Owner

@xavier2k6 commented on GitHub (May 15, 2024):

@Chocobo1 @Piccirello Is there anything that can be done about this? users currently have to append a / to url to workaround.

@xavier2k6 commented on GitHub (May 15, 2024): @Chocobo1 @Piccirello Is there anything that can be done about this? users currently have to append a `/` to url to workaround.

deekerman commented

Author

Owner

@Chocobo1 commented on GitHub (May 15, 2024):

@Chocobo1 @Piccirello Is there anything that can be done about this? users currently have to append a / to url to workaround.

PR #20442 may remedy it.

@Chocobo1 commented on GitHub (May 15, 2024): >@Chocobo1 @Piccirello Is there anything that can be done about this? users currently have to append a / to url to workaround. PR #20442 may remedy it.

deekerman commented

Author

Owner

@johmei4 commented on GitHub (Jun 16, 2024):

In windows 11, FF something or nother (newest version I don't know, it doesn't seem to matter which version based on people having this problem for 5 years), I'm experiencing this exact same issue. I click login and the page just refreshes, and the user name and password are blank. I can proceed to go up to the URL, add http:// (which presumably was there, but I don't know since web browsers decided to just hide that part in the URL bars) and once I add that and hit enter, it works. The qbittorrent container's value for net.unraid.docker.webui is http://[IP]:[PORT:8081], so the http:// should be there, I'm not sure why going up to the URL and putting it in there makes the UI come up.

When I enter the URL into chrome, it works. It also works when I open the qBittorrent webui from Unraid's docker interface in chrome, just not in firefox.

@johmei4 commented on GitHub (Jun 16, 2024): In windows 11, FF something or nother (newest version I don't know, it doesn't seem to matter which version based on people having this problem for 5 years), I'm experiencing this exact same issue. I click login and the page just refreshes, and the user name and password are blank. I can proceed to go up to the URL, add http:// (which presumably was there, but I don't know since web browsers decided to just hide that part in the URL bars) and once I add that and hit enter, it works. The qbittorrent container's value for net.unraid.docker.webui is http://[IP]:[PORT:8081], so the http:// should be there, I'm not sure why going up to the URL and putting it in there makes the UI come up. When I enter the URL into chrome, it works. It also works when I open the qBittorrent webui from Unraid's docker interface in chrome, just not in firefox.

deekerman commented

Author

Owner

@luzpaz commented on GitHub (Aug 8, 2024):

Is this issue still occurring in latest stable ?

@luzpaz commented on GitHub (Aug 8, 2024): Is this issue still occurring in latest stable ?

deekerman commented

Author

Owner

@GeoffreyCoulaud commented on GitHub (Aug 10, 2024):

Yes, unfortunately it still happens on 4.6.5 @luzpaz

@GeoffreyCoulaud commented on GitHub (Aug 10, 2024): Yes, unfortunately it still happens on `4.6.5` @luzpaz

deekerman commented

Author

Owner

@xavier2k6 commented on GitHub (Aug 10, 2024):

@luzpaz I don't believe that this was able to be backported, a test of latest master build would be more informative.

@xavier2k6 commented on GitHub (Aug 10, 2024): @luzpaz I don't believe that this was able to be backported, a test of latest `master` build would be more informative.

deekerman commented

Author

Owner

@MDKAOD commented on GitHub (Jan 2, 2025):

I believe I'm running into the same issue with qBittorrent v4.6.2 and firefox 120.0.1. Logging in just takes me back to the log in screen. Removing the trailing slash then loads the full UI for me.

I need to ADD the trailing slash to get my web UI to load. 🤔

@MDKAOD commented on GitHub (Jan 2, 2025): > I believe I'm running into the same issue with qBittorrent v4.6.2 and firefox 120.0.1. Logging in just takes me back to the log in screen. _Removing_ the trailing slash then loads the full UI for me. I need to ADD the trailing slash to get my web UI to load. 🤔

deekerman commented

Author

Owner

@GeoffreyCoulaud commented on GitHub (Jan 6, 2025):

For what it's worth, I've never had the issue after I added a local domain name to qbittorrent, and used port 80 for the web ui.

I've done that with a local docker setup, using wireguard + coredns + a homemade project, daenes for local DNS.

That way, i can access qbittorrent with a domain name (eg. qbittorrent.internal) when connected to my wireguard tunnel.

The fact that this solved the issue makes it look like the problem comes from some kind of redirect that doesn't happen correctly, in my opinion.

@GeoffreyCoulaud commented on GitHub (Jan 6, 2025): For what it's worth, I've never had the issue after I added a local domain name to qbittorrent, and used port 80 for the web ui. I've done that with a local docker setup, using wireguard + coredns + a homemade project, [daenes](https://github.com/GeoffreyCoulaud/daenes) for local DNS. That way, i can access qbittorrent with a domain name (eg. `qbittorrent.internal`) when connected to my wireguard tunnel. --- The fact that this solved the issue makes it look like the problem comes from some kind of redirect that doesn't happen correctly, in my opinion.

deekerman commented

Author

Owner

@TheTitanius commented on GitHub (Feb 17, 2025):

I need to ADD the trailing slash to get my web UI to load. 🤔

I faced this problem and adding trailing slash solved this

@TheTitanius commented on GitHub (Feb 17, 2025): > I need to ADD the trailing slash to get my web UI to load. 🤔 I faced this problem and adding trailing slash solved this

deekerman commented

Author

Owner

@luzpaz commented on GitHub (Mar 6, 2025):

@TheTitanius full version of qbt ?

@luzpaz commented on GitHub (Mar 6, 2025): @TheTitanius full version of qbt ?

deekerman commented

Author

Owner

@TheTitanius commented on GitHub (Mar 7, 2025):

@TheTitanius полная версия qbt ?

5.0.3

@TheTitanius commented on GitHub (Mar 7, 2025): > [@TheTitanius](https://github.com/TheTitanius) полная версия qbt ? 5.0.3

deekerman commented

Author

Owner

@luzpaz commented on GitHub (Mar 15, 2025):

Removed the "Can't reproduce' as user can still reproduce

@luzpaz commented on GitHub (Mar 15, 2025): Removed the "Can't reproduce' as user can still reproduce

deekerman commented

Author

Owner

@glassez commented on GitHub (Mar 15, 2025):

Removed the "Can't reproduce' as user can still reproduce

This label means that qBittorrent bug handlers (or someone else) were unable to reproduce it by following Steps to reproduce provided by the Issue reporter.

@glassez commented on GitHub (Mar 15, 2025): > Removed the "Can't reproduce' as user can still reproduce This label means that qBittorrent bug handlers (or someone else) were unable to reproduce it by following **Steps to reproduce** provided by the Issue reporter.

deekerman commented

Author

Owner

@luzpaz commented on GitHub (Mar 15, 2025):

@glassez indeed. If i may, the exception here is that was issued back in 2020 and users are still reproducing this as of last week.

@luzpaz commented on GitHub (Mar 15, 2025): @glassez indeed. If i may, the exception here is that was issued back in 2020 and users are still reproducing this as of last week. ![Image](https://github.com/user-attachments/assets/7be4651a-3141-42a0-b719-d6a467681332)

deekerman commented

Author

Owner

@glassez commented on GitHub (Mar 18, 2025):

Just tested with Firefox 136.0.1

qBittorrent 5.0.4 (official AppImage)
Qt: 6.7.3
Libtorrent: 1.2.20.0
Boost: 1.86.0
OpenSSL: 3.4.1
zlib: 1.3

Can't reproduce.

qBittorrent 5.0.3 (official qBittorrent-nox Docker Image)
Qt: 6.8.0
Libtorrent: 1.2.19.0
Boost: 1.86.0
OpenSSL: 3.3.2
zlib: 1.3.1

Can't reproduce.

@glassez commented on GitHub (Mar 18, 2025): Just tested with Firefox 136.0.1 qBittorrent 5.0.4 (official AppImage) Qt: 6.7.3 Libtorrent: 1.2.20.0 Boost: 1.86.0 OpenSSL: 3.4.1 zlib: 1.3 **Can't reproduce.** ![Image](https://github.com/user-attachments/assets/b9c6a419-5241-48eb-91e7-769c7face640) qBittorrent 5.0.3 (official qBittorrent-nox Docker Image) Qt: 6.8.0 Libtorrent: 1.2.19.0 Boost: 1.86.0 OpenSSL: 3.3.2 zlib: 1.3.1 **Can't reproduce.**

deekerman commented

Author

Owner

@glassez commented on GitHub (Mar 18, 2025):

Is there something else that affects this? For example, a reverse proxy.

@glassez commented on GitHub (Mar 18, 2025): Is there something else that affects this? For example, a reverse proxy.

deekerman commented

Author

Owner

@johnhelt commented on GitHub (Mar 18, 2025):

For me this occurs when I have multiple instances running. Then the one instance that runs the ui on the non-default port, is the one I can't access on login, but have to add a trailing slash.

@johnhelt commented on GitHub (Mar 18, 2025): For me this occurs when I have multiple instances running. Then the one instance that runs the ui on the non-default port, is the one I can't access on login, but have to add a trailing slash.

deekerman commented

Author

Owner

@GeoffreyCoulaud commented on GitHub (Mar 18, 2025):

I concur with @johnhelt, when I had the problem, I was using non-default ports on both instances to avoid collisions

@GeoffreyCoulaud commented on GitHub (Mar 18, 2025): I concur with @johnhelt, when I had the problem, I was using non-default ports on both instances to avoid collisions

deekerman commented

Author

Owner

@xavier2k6 commented on GitHub (Mar 18, 2025):

similar/related - #13405

@xavier2k6 commented on GitHub (Mar 18, 2025): similar/related - #13405

deekerman commented

Author

Owner

@leviska commented on GitHub (Mar 19, 2025):

Same, opens fine in chrome, but not in ff
Console logs:

@leviska commented on GitHub (Mar 19, 2025): Same, opens fine in chrome, but not in ff Console logs: ![Image](https://github.com/user-attachments/assets/092bad76-a4c3-4b81-976c-9940f3821564) ![Image](https://github.com/user-attachments/assets/58911f23-e1b6-40cf-b7f7-0c438c53135f)

deekerman commented

Author

Owner

@sebingel commented on GitHub (Aug 17, 2025):

Same problem for me today.
qBittorrent v5.1.2 WebUI (64-bit) hosted in docker.
firefox 141.0.3 (64-Bit) on windows 11
qBittorrent web ui is accessed through Caddy2 as a reverse proxy for https.

Login page just refreshed. Removed and readded trailing slash and I was already logged on and saw the web interface.

@sebingel commented on GitHub (Aug 17, 2025): Same problem for me today. qBittorrent v5.1.2 WebUI (64-bit) hosted in docker. firefox 141.0.3 (64-Bit) on windows 11 qBittorrent web ui is accessed through Caddy2 as a reverse proxy for https. Login page just refreshed. Removed and readded trailing slash and I was already logged on and saw the web interface.

deekerman commented

Author

Owner

@tasteweb commented on GitHub (Sep 13, 2025):

Same issue.

@tasteweb commented on GitHub (Sep 13, 2025): Same issue.

deekerman commented

Author

Owner

@samudotlol commented on GitHub (Sep 16, 2025):

Same issue here.
qBittorrent v5.1.2 WebUI (64-bit) hosted on Podman
Firefox 142.0.1 (64-bit)
I am accessing the WebUI directly using IP and port. Adding the trailing slash fixes it

@samudotlol commented on GitHub (Sep 16, 2025): Same issue here. qBittorrent v5.1.2 WebUI (64-bit) hosted on Podman Firefox 142.0.1 (64-bit) I am accessing the WebUI directly using IP and port. Adding the trailing slash fixes it

deekerman commented

Author

Owner

@OnlyIfUSayPlz commented on GitHub (Oct 13, 2025):

Same issue. qBittorrent 5.1.2 running on Docker through Unraid 7.1.4 accessing through Firefox 143.0.4 on Windows 10 22H2. Maybe worth noting that I can access the WebUI when I use a private window (aka incognito mode).

@OnlyIfUSayPlz commented on GitHub (Oct 13, 2025): Same issue. qBittorrent 5.1.2 running on Docker through Unraid 7.1.4 accessing through Firefox 143.0.4 on Windows 10 22H2. Maybe worth noting that I can access the WebUI when I use a private window (aka incognito mode).

deekerman commented