Open WeirDave opened 5 years ago
Can not reproduce the issue on Windows 10.
I am on Windows 10. It works fine for me on Chrome but not in Firefox
Opens fine for me on 66.0.2 on win 10
Okay what can I do to fix?
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.
qBittorrent 4.1.3 (64-bit)
The latest version is 4.1.5.
I have 4.1.5
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.
Cannot reproduce on Ubuntu 18.04 LTS or Windows 10.
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.
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
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.
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.
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:
<a href="https://192.168.1.1">qBittorrent site</a>
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.
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 🤔
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 : 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.
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.
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.
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:
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:
/
at the end of the url, get magically redirected back to w/o /
but in the normal -logged in- state/
at the end of the url without logging in at all, get magically redirected back to w/o /
but in the normal -logged in- stateCould this have something to do with some redirections?
I have exactly the same problem. FF 74.0 on Macos, Qbittorrent 4.2.1
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.
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).
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
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
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 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.
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?
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 theCookie
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/
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:
<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 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
.
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.
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...
- 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.
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 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 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
@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.
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
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.
@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.
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
?
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
Hello,
Managed to create a capture without https.
I did the following in this:
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 .
@Piccirello @FranciscoPombal Is this still an issue or can this be closed?
@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.
@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).
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...
Yeah I'm still getting this
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)