Cant Authenticate Qbittorrent container webui with 3rd Party apps

[khanmania2050]

Hi everyone,

I'm setting up a mobile companion app (Directarr) to manage my qBittorrent instance remotely behind a reverse proxy / tunnel.

While services like Radarr/Sonarr manage to connect to qBittorrent without issue, 3rd-party companion mobile apps fail when attempting to log in via /api/v2/auth/login using standard username and password credentials.

When testing the login endpoint via curl:

curl -i -d "username=admin&password=YOUR_PASSWORD" http://<IP>:<PORT>/api/v2/auth/login





The server returns:

HTTP
HTTP/1.1 204 OK
set-cookie: QBT_SID_<PORT>=...; HttpOnly; expires=...; path=/


If I manually extract the QBT_SID_<PORT> value and pass it as a static Cookie header in the app, the connection works. However, doing this manually isn't ideal since the session drops whenever the daemon restarts, and bypassing subnet authentication isn't safe for a remotely accessible instance.

My questions:
What is the recommended way for 3rd-party/mobile API clients to handle authentication so they can maintain a persistent, secure session like other Arr apps do?
Is there a specific header or configuration required on the client side when negotiating the QBT_SID_<PORT> cookie through a reverse proxy?
Thanks for any insights or suggestions!

[MLuc24]

Auth isn't failing — that 204 with a Set-Cookie is qBittorrent telling you the login succeeded. The app is failing to pick the cookie up, which is a different problem and explains why pasting it by hand works.

The likely reason is the cookie's name. qBittorrent builds it from the configured WebUI port:

const QString SESSION_COOKIE_NAME_PREFIX = u"QBT_SID_"_s;

m_sessionCookieName = SESSION_COOKIE_NAME_PREFIX + QString::number(pref->getWebUIPort());

Two things fall out of that. Older qBittorrent used a plain SID, so any app coded against that looks for a name the server no longer sends and comes up empty. And getWebUIPort() is qBittorrent's own configured port, not the port the client connected on — so behind your reverse proxy or tunnel, an app that tries to derive the name from the URL it dialled will guess wrong too. You'd see exactly this: login succeeds, nothing is stored, every subsequent request is unauthenticated.

Radarr and Sonarr work because they use a normal cookie jar that stores whatever name arrives rather than looking for a specific one.

Rather than fight that, the better fit for a third-party app is the API key, since qBittorrent accepts bearer tokens:

const bool isUsingApiKey = (authScheme.compare(BEARER_AUTH, Qt::CaseInsensitive) == 0);

So generate a key in the WebUI and have the app send Authorization: Bearer <key> on each request. No login call, no cookie to capture, nothing that depends on the port — which is what you want across a tunnel anyway, and it survives session timeouts that would otherwise log the app out. Worth checking whether Directarr supports an API key field; if it does, that's the whole fix.

If it only speaks username and password, then it's a bug on their side worth reporting as "does not persist the QBT_SID_* session cookie", which is a much more actionable report than "can't authenticate".

[khanmania2050]

Thanks it worked using the custom header : Authorization: Basic <base64(username:password)>

[zonked-ui]

Title: WebUI Options dialog: Save button non‑functional on WebUI and Downloads pages (Debian 13 Qt6 build)
Environment
OS: Debian 13 (Trixie)

Package: qBittorrent 5.x from Debian archive

Build: Qt6

Interface: WebUI

Browser: Any (tested in Edge, Firefox, Chromium)

Summary
The Save button inside the WebUI Options dialog is non‑functional on two specific pages:

WebUI

Downloads

Clicking Save on these pages does not write any settings, does not send a POST request, and simply scrolls the page upward. No changes are saved, no config updates occur, and no errors are logged.

Saving from other pages (e.g., General, Connection, Speed, Advanced) works normally.

This regression breaks WebUI configuration and also disables the WebAPI magnet POST endpoint until a valid Preferences write occurs.

Symptoms
❌ Broken pages
WebUI → Save does nothing

Downloads → Save does nothing

Page scrolls upward

No POST request sent

No config writes

No Preferences update

No password hash written

No directory changes saved

No WebUI settings saved

No error messages

✔ Working pages
General → Save works

Connection → Save works

Speed → Save works

Advanced → Save works

Saving from these pages correctly writes the config, updates Preferences, writes the PBKDF2 hash, and closes the dialog.

Impact
This regression causes:

WebUI password changes to fail

Save path changes to fail

Incomplete/complete directory changes to fail

WebUI settings changes to fail

Preferences subsystem to remain uninitialised

WebAPI magnet POST (/api/v2/torrents/add) to silently fail

Automation pipelines relying on magnet forwarding to break

The failure is silent and difficult for users to diagnose.

Reproduction Steps
Install qBittorrent 5.x from Debian 13 repository

Open WebUI

Go to Options → WebUI

Change any setting

Click Save

Observe: page scrolls up, nothing saved

Go to Options → Downloads

Change any setting

Click Save

Same behaviour: scrolls up, nothing saved

Go to Options → General

Click Save

Settings save correctly, dialog closes

Workaround
Make changes on WebUI or Downloads pages

Switch to General (or any working page)

Click Save

Settings save correctly

This workaround confirms the backend Preferences write‑path is functional and the issue is isolated to page‑local handlers.

Expected Behaviour
Save button should work on all pages of the Options dialog

POST request should be sent

Preferences should update

Config should write

WebAPI should remain functional

Actual Behaviour
Save button is broken on WebUI and Downloads pages

No POST request

No config write

No Preferences update

WebAPI magnet POST fails until a valid Preferences write occurs

Notes
This appears to be a Qt6 page‑local handler regression affecting only certain pages in the Options dialog.
Other pages use a global Preferences write‑handler and work correctly.

I cannot create new Discussions due to repository restrictions. Could a maintainer please convert this into a bug report?