starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

WebUI: stuck on login screen with firefox for android (both windows and linux qbittorrent) #10912

New issue

Open

opened 2026-02-21 21:02:22 -05:00 by deekerman · 16 comments

deekerman commented

2026-02-21 21:02:22 -05:00

Owner

Originally created by @leterio on GitHub (Sep 18, 2020).

Please provide the following information

qBittorrent version and Operating System

qBittorrent v4.2.5 (linux and windows versions)

What is the problem

The WebUI stuck on login when accessing with firefox for android (80.1.3)
No username or passowrd error is show

What is the expected behavior

Access WebUI without problems when using firefox for android (latest version)

Steps to reproduce

Run qBittorrent with WebUI enabled
Access qBittorrent WebUI "address:port" with firefox for android (latest version possible)
Try to login with the correct password

Extra info(if any)

No problems when accessing with Edge (chromium based) (both linux server and windows)

On linux, running the docker container linuxserver/qbittorrent
On Windows, installed from official installer

Originally created by @leterio on GitHub (Sep 18, 2020). **Please provide the following information** ### qBittorrent version and Operating System qBittorrent v4.2.5 (linux and windows versions) ### What is the problem The WebUI stuck on login when accessing with firefox for android (80.1.3) No username or passowrd error is show ### What is the expected behavior Access WebUI without problems when using firefox for android (latest version) ### Steps to reproduce Run qBittorrent with WebUI enabled Access qBittorrent WebUI "address:port" with firefox for android (latest version possible) Try to login with the correct password ### Extra info(if any) No problems when accessing with Edge (chromium based) (both linux server and windows) On linux, running the docker container linuxserver/qbittorrent On Windows, installed from official installer

deekerman added the

WebUI

Can't reproduce

labels

2026-02-21 21:02:22 -05:00

deekerman commented

2026-02-21 21:02:24 -05:00

Author

Owner

@Matth7878 commented on GitHub (Sep 19, 2020):

Same here on Firefox Nightly for Android.
On chrome (still Android) it's working.
=> It probably means problem lies with Firefox ? Maybe it should be reported on Fenix GitHub ?

@Matth7878 commented on GitHub (Sep 19, 2020): Same here on Firefox Nightly for Android. On chrome (still Android) it's working. => It probably means problem lies with Firefox ? Maybe it should be reported on Fenix GitHub ?

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@frapgadz commented on GitHub (Oct 16, 2020):

I have this issue too on both 81.1.4 and Firefox Nightly for Android, the webui for qbittorent works on Chrome on the same device.

@frapgadz commented on GitHub (Oct 16, 2020): I have this issue too on both 81.1.4 and Firefox Nightly for Android, the webui for qbittorent works on Chrome on the same device.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@Combinatix commented on GitHub (Nov 4, 2020):

I have this problem too, on FF for Android ver. 82.1.1, qBittorrent v. 4.3.0.1
I use web ui on port 85 and I access it from public internet (over IPv4 + NAT). Firstly I have noticed that I have to write http:// before the host name, otherwise I have seen only a blank screen. I also experienced few firefox crashes during trying!! When I write the full address, like http://my.host.name:85 then I see login screen. But when I enter correct credentials I got back to login screen. Chrome for android works fine. I suspect this is more likely the Firefox problem, but it could be some UI error.

Do you guys access the WebUI with port specified in URL? What about the firewall with NAT?

@Combinatix commented on GitHub (Nov 4, 2020): I have this problem too, on FF for Android ver. 82.1.1, qBittorrent v. 4.3.0.1 I use web ui on port 85 and I access it from public internet (over IPv4 + NAT). Firstly I have noticed that I have to write http:// before the host name, otherwise I have seen only a blank screen. I also experienced few firefox crashes during trying!! When I write the full address, like http://my.host.name:85 then I see login screen. But when I enter correct credentials I got back to login screen. Chrome for android works fine. I suspect this is more likely the Firefox problem, but it could be some UI error. Do you guys access the WebUI with port specified in URL? What about the firewall with NAT?

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@ghost commented on GitHub (Dec 6, 2020):

I'm serving it behind a Apache reverse proxy, cannot pass the auth page on Firefox for Android. PC works fine.

@ghost commented on GitHub (Dec 6, 2020): I'm serving it behind a Apache reverse proxy, cannot pass the auth page on Firefox for Android. PC works fine.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@vialou commented on GitHub (Apr 21, 2021):

I am having this issue since a couple of months.
Reproducing on firefox, edge, chrome, safari. All are in the last version.

I am using a docker container on raspbian running on a raspberry Pi4.
Everything was working fine and an update brought this issue.

The CLI configuration for the docker container:

docker run -d --name qbittorrent
-e PUID=1000
-e PGID=1000
-e TZ=Europe/London
-e WEBUI_PORT=8090
-p 6881:6881
-p 6881:6881/udp
-p 8090:8090
-v /docker/qbittorrent/config:/config
-v /media/Downloads:/downloads
--restart unless-stopped
linuxserver/qbittorrent:latest

How can I fix it?

@vialou commented on GitHub (Apr 21, 2021): I am having this issue since a couple of months. Reproducing on firefox, edge, chrome, safari. All are in the last version. I am using a docker container on raspbian running on a raspberry Pi4. Everything was working fine and an update brought this issue. The CLI configuration for the docker container: docker run -d --name qbittorrent \ -e PUID=1000 \ -e PGID=1000 \ -e TZ=Europe/London \ -e WEBUI_PORT=8090 \ -p 6881:6881 \ -p 6881:6881/udp \ -p 8090:8090 \ -v /docker/qbittorrent/config:/config \ -v /media/Downloads:/downloads \ --restart unless-stopped \ linuxserver/qbittorrent:latest How can I fix it?

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@Matth7878 commented on GitHub (Apr 24, 2021):

I tried right now to log to WebUI with latest Firefox nightly for Android. I was expecting it not working (like previous time) but it did!

@Matth7878 commented on GitHub (Apr 24, 2021): I tried right now to log to WebUI with latest Firefox nightly for Android. I was expecting it not working (like previous time) but it did!

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@Combinatix commented on GitHub (Apr 25, 2021):

No luck here. I have tried it right now, with Firefox Nightly, http://hostname:85 > I see blank screen. (FF Nightly 210424 17:00)
It works as expected in Chrome for Android
@Matth7878 Did you use hostname:port url?

@Combinatix commented on GitHub (Apr 25, 2021): No luck here. I have tried it right now, with Firefox Nightly, http://hostname:85 > I see blank screen. (FF Nightly 210424 17:00) It works as expected in Chrome for Android @Matth7878 Did you use hostname:port url?

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@Matth7878 commented on GitHub (Apr 25, 2021):

@Matth7878 Did you use hostname:port url?

I use : http://192.168.1.10:8080/
My Firefox version : Nightly 210424 17:00 (Build #2015806539)
Qbittorrent is the latest official for windows and 64bits.
WebUI in title is 4.3.4.1

I tried again this morning and still working! Don't know when it started working but before I was stuck at login screen.

@Matth7878 commented on GitHub (Apr 25, 2021): > @Matth7878 Did you use hostname:port url? I use : http://192.168.1.10:8080/ My Firefox version : Nightly 210424 17:00 (Build #2015806539) Qbittorrent is the latest official for windows and 64bits. WebUI in title is 4.3.4.1 I tried again this morning and still working! Don't know when it started working but before I was stuck at login screen.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@reeseovine commented on GitHub (Nov 25, 2021):

I'm having the same issue with Firefox for Linux and Android, but surprisingly I am able to log in when using private browsing mode. This issue doesn't happen with Chromium.

My qbittorrent instance is on a Linux computer with linuxserver.io's docker image.

@reeseovine commented on GitHub (Nov 25, 2021): I'm having the same issue with Firefox for Linux and Android, but surprisingly I am able to log in when using private browsing mode. This issue doesn't happen with Chromium. My qbittorrent instance is on a Linux computer with linuxserver.io's docker image.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@mynameisbogdan commented on GitHub (Mar 25, 2022):

Same issue with Firefox on Mac, using ip+port url.

Seems related in some way to SameSite=Strict added to the cookie session, so setting WebUI\CSRFProtection=false (or disabling Enable Cross-Site Request Forgery (CSRF) protection from the webui settings using another browser) "fixed" the login for me.

@mynameisbogdan commented on GitHub (Mar 25, 2022): Same issue with Firefox on Mac, using ip+port url. Seems related in some way to `SameSite=Strict` added to the cookie session, so setting `WebUI\CSRFProtection=false` (or disabling `Enable Cross-Site Request Forgery (CSRF) protection` from the webui settings using another browser) "fixed" the login for me.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@walidjami commented on GitHub (Sep 28, 2022):

Is there a solution to this? I can access webgui from chrome but not from firefox

@walidjami commented on GitHub (Sep 28, 2022): Is there a solution to this? I can access webgui from chrome but not from firefox

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@haarp commented on GitHub (Nov 21, 2022):

Can confirm on Firefox 104 on Linux (not Android). It looks like the cookie is not being sent properly, as this can be found in the browser log: Cookie “SID” with the “SameSite” attribute value “Lax” or “Strict” was omitted because of a cross-site redirect.

@mynameisbogdan's workaround works. Disable CSRF protection, delete the SID cookie, then you can log-in again.

@haarp commented on GitHub (Nov 21, 2022): Can confirm on Firefox 104 on Linux (not Android). It looks like the cookie is not being sent properly, as this can be found in the browser log: `Cookie “SID” with the “SameSite” attribute value “Lax” or “Strict” was omitted because of a cross-site redirect.` @mynameisbogdan's workaround works. Disable CSRF protection, delete the SID cookie, then you can log-in again.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@wafflecomposite commented on GitHub (May 15, 2023):

Just stumbled across this. For anyone struggling with this, try adding slash to the url
(ex. http://192.168.1.10:8080 -> http://192.168.1.10:8080/)
after login attempt that was redirected back to login form.

Then if this works and you can get into the interface, logout and try again, that fixed the non-slash link for me too. Or you can just add a link with a slash to your bookmarks I guess.

@wafflecomposite commented on GitHub (May 15, 2023): Just stumbled across this. For anyone struggling with this, try adding slash to the url (ex. http://192.168.1.10:8080 -> http://192.168.1.10:8080/) after login attempt that was redirected back to login form. Then if this works and you can get into the interface, logout and try again, that fixed the non-slash link for me too. Or you can just add a link with a slash to your bookmarks I guess.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@luzpaz commented on GitHub (Dec 10, 2023):

Just stumbled across this. For anyone struggling with this, try adding slash to the url
(ex. http://192.168.1.10:8080/ -> http://192.168.1.10:8080/)
after login attempt that was redirected back to login form.

Can we code something to avoid this discrepancy ?

@luzpaz commented on GitHub (Dec 10, 2023): > Just stumbled across this. For anyone struggling with this, try adding slash to the url (ex. http://192.168.1.10:8080/ -> http://192.168.1.10:8080/) after login attempt that was redirected back to login form. Can we code something to avoid this discrepancy ?

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@gw17252009 commented on GitHub (Jan 13, 2025):

@mynameisbogdan, disabling CSRF worked for me.

@gw17252009 commented on GitHub (Jan 13, 2025): @mynameisbogdan, disabling CSRF worked for me.

deekerman commented

2026-02-21 21:02:27 -05:00

Author

Owner

@Fabiejan commented on GitHub (Dec 11, 2025):