search

qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
26.84k stars 3.87k forks source link

Web UI does not open with Firefox 66.0.1 #10405

Open WeirDave opened 5 years ago

WeirDave commented 5 years ago

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 commented 5 years ago

Can not reproduce the issue on Windows 10.

WeirDave commented 5 years ago

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

jobrien2001 commented 5 years ago

Opens fine for me on 66.0.2 on win 10

WeirDave commented 5 years ago

Okay what can I do to fix?

facemanak commented 5 years ago

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 commented 5 years ago

qBittorrent 4.1.3 (64-bit)

The latest version is 4.1.5.

WeirDave commented 5 years ago

I have 4.1.5

facemanak commented 5 years ago

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 commented 5 years ago

Cannot reproduce on Ubuntu 18.04 LTS or Windows 10.

adem4ik commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 5 years ago

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 commented 5 years ago

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:

aelfwine88 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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: 0000000643

Could this have something to do with some redirections?

daddyboo commented 4 years ago

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

0x49D1 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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/
aelfwine88 commented 4 years ago

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:

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

Piccirello commented 4 years ago

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.

Screen Shot 2020-04-09 at 3 14 37 AM Screen Shot 2020-04-09 at 3 20 20 AM
aelfwine88 commented 4 years ago

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 4 years ago

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...
Piccirello commented 4 years ago
  • 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.

Screen Shot 2020-04-09 at 3 29 11 AM

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.

aelfwine88 commented 4 years ago

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.

FranciscoPombal commented 4 years ago

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

aelfwine88 commented 4 years ago

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

FranciscoPombal commented 4 years ago

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

aelfwine88 commented 4 years ago

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

FranciscoPombal commented 4 years ago

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 4 years ago

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

Piccirello commented 4 years ago

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?

aelfwine88 commented 4 years ago

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 4 years ago

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 .

xavier2k6 commented 3 years ago

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

FranciscoPombal commented 3 years ago

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

Themis3000 commented 3 years ago

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

dejjem commented 3 years ago

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

brzzdev commented 2 years ago

Yeah I'm still getting this