qBitTorrent 5.2+ auth BC break #11

New issue

Closed

opened 2026-05-11 16:40:13 +03:00 by skobkin · 0 comments

skobkin commented

2026-05-11 16:40:13 +03:00

Owner

Problem

qBtRemoteGo fails to authenticate against qBittorrent 5.2.0+.

Observed error:

Last error: auth/login returned 204 OK

qBittorrent 5.2.0 changed WebAPI behavior: successful API responses with no body may now return HTTP 204 No Content instead of 200 OK.

The current client code treats only 200 OK with body Ok. / Ok as a successful login, so a valid 204 login response is incorrectly handled as an error.

Expected behavior

Authentication should succeed for both supported qBittorrent login response styles:

legacy behavior: 200 OK with body Ok. / Ok
qBittorrent 5.2.0+ behavior: 204 No Content with empty body

The client should continue relying on Go's existing cookiejar handling and must not hardcode the qBittorrent session cookie name.

Scope

Fix only username/password WebAPI login compatibility.

Do not implement API key authentication in this issue.

Implementation notes

Relevant code:

internal/qbt/client.go

ensureAuthenticated(ctx) should:

accept 200 OK with body Ok. / Ok
accept 204 No Content as successful login without reading/expecting a body
keep rejecting 200 OK with body Fails. / Fails
keep returning useful errors for other HTTP statuses
set c.authenticated = true after successful login
avoid hardcoding cookie names such as SID

Tests

Add/update tests in:

internal/qbt/client_test.go

Required coverage:

successful legacy login: 200 OK + Ok.
successful qBittorrent 5.2.0+ login: 204 No Content + Set-Cookie
failed login: 200 OK + Fails.
rejected status: 401 or 403

Acceptance criteria

qBtRemoteGo authenticates successfully against qBittorrent 5.2.0+
the error auth/login returned 204 OK no longer appears for successful login
legacy 200 OK login behavior remains supported
existing tests pass
new tests cover the 204 login path

## Problem qBtRemoteGo fails to authenticate against qBittorrent 5.2.0+. Observed error: ```text Last error: auth/login returned 204 OK ``` qBittorrent 5.2.0 changed WebAPI behavior: successful API responses with no body may now return HTTP `204 No Content` instead of `200 OK`. The current client code treats only `200 OK` with body `Ok.` / `Ok` as a successful login, so a valid `204` login response is incorrectly handled as an error. ## Expected behavior Authentication should succeed for both supported qBittorrent login response styles: - legacy behavior: `200 OK` with body `Ok.` / `Ok` - qBittorrent 5.2.0+ behavior: `204 No Content` with empty body The client should continue relying on Go's existing `cookiejar` handling and must not hardcode the qBittorrent session cookie name. ## Scope Fix only username/password WebAPI login compatibility. Do not implement API key authentication in this issue. ## Implementation notes Relevant code: ```text internal/qbt/client.go ``` `ensureAuthenticated(ctx)` should: - accept `200 OK` with body `Ok.` / `Ok` - accept `204 No Content` as successful login without reading/expecting a body - keep rejecting `200 OK` with body `Fails.` / `Fails` - keep returning useful errors for other HTTP statuses - set `c.authenticated = true` after successful login - avoid hardcoding cookie names such as `SID` ## Tests Add/update tests in: ```text internal/qbt/client_test.go ``` Required coverage: - successful legacy login: `200 OK` + `Ok.` - successful qBittorrent 5.2.0+ login: `204 No Content` + `Set-Cookie` - failed login: `200 OK` + `Fails.` - rejected status: `401` or `403` ## Acceptance criteria - qBtRemoteGo authenticates successfully against qBittorrent 5.2.0+ - the error `auth/login returned 204 OK` no longer appears for successful login - legacy `200 OK` login behavior remains supported - existing tests pass - new tests cover the `204` login path

skobkin added the

bug

label

2026-05-11 16:40:13 +03:00

skobkin self-assigned this

2026-05-11 16:40:13 +03:00

skobkin referenced this issue from a commit

2026-05-11 17:30:56 +03:00

fix(qbt): fixing BC break in auth introduced in qBt 5.2.0 (closes #11)

skobkin closed this issue

2026-05-11 18:47:29 +03:00