Web UI does not open with Firefox 66.0.1

[WeirDave]

Please provide the following information

qBittorrent version and Operating System

4.1.5

If on linux, libtorrent and Qt version

QNAP NAS - https://www.qnapclub.eu/en/qpkg/507

What is the problem

Opens just fine in Chrome but not in Firefox

What is the expected behavior

Open after entering credentials

Steps to reproduce

Gets to login screen. Submit login information and it just resets back to login screen

Extra info(if any)

(type here)

[adem4ik]

Can not reproduce the issue on Windows 10.

[WeirDave]

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

[jobrien2001]

Opens fine for me on 66.0.2 on win 10

[WeirDave]

Okay what can I do to fix?

[facemanak]

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.

[adem4ik]

qBittorrent 4.1.3 (64-bit)

The latest version is 4.1.5.

[WeirDave]

I have 4.1.5

[facemanak]

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.

[FranciscoPombal]

Cannot reproduce on Ubuntu 18.04 LTS or Windows 10.

[adem4ik]

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.

[WeirDave]

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

[facemanak]

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]

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.

[aelfwine88]

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]

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.

[0xbbadbeef]

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 🤔

[Piccirello]

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.

[aelfwine88]

@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.

[Lentolo]

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.

[ismay]

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.

[TheBestPessimist]

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

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?

[daddyboo]

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

[0x49D1]

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.

[FranciscoPombal]

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).

[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.

[FranciscoPombal]

@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.

[aelfwine88]

@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.

[FranciscoPombal]

@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.

[aelfwine88]

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?

[Piccirello]

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

 $ 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/