Support qBittorrent 5.2 API key authentication - #367
Conversation
| self.name = name | ||
| if not self.name: | ||
| logger.verbose( | ||
| "No name provided for qbittorrent client, assuming 'qBitorrent'. If the name used in your *arr is different, please correct either the name in your *arr, or set the name in your config", | ||
| ) | ||
| self.name = "qBittorrent" | ||
|
|
||
| if self.api_key and (username or password): |
There was a problem hiding this comment.
Would it make sense to also add
a) an error that qbit needs to be updated for api key to be supported (if api_key and qbitversion < 5.2)?
b) a recommendation to switch from password to api key (if (username or password) and qbitversion >= 5.2)?
There was a problem hiding this comment.
Yes, both are useful, with one limitation:
a) If api_key is configured and we successfully retrieve a qBittorrent version below 5.2, we should warn that the configured API key is unsupported and is not providing authentication. We should not fail the application or remove support for older qBittorrent versions.
If the initial Bearer request returns 403, we cannot retrieve the version because /app/version itself requires authentication. That response can mean either an invalid key on 5.2+ or an older server without API-key support, so the existing combined troubleshooting message remains necessary.
b) If username/password is configured and the retrieved version is 5.2+, we can reliably log an informational recommendation to switch to an API key while continuing normally.
I’ll add both post-version guidance checks without changing the existing qBittorrent 4.3 minimum or making API keys mandatory.
There was a problem hiding this comment.
Sorry - forgot to post that earlier. Anywho:
Updated in 701f67f. Added the post-version warning for API key + qBittorrent below 5.2 and the recommendation for username/password + qBittorrent 5.2+. These are guidance-only and do not change supported versions or authentication behavior. The existing ambiguous-403 handling remains unchanged. All 37 relevant tests pass. Ready for re-review.
ccb500b to
701f67f
Compare
qBittorrent 5.2 added stateless API-key auth (Authorization: Bearer), which lets users avoid storing username/password credentials. This adds an optional `api_key` field to qBittorrent clients and makes it the recommended auth path; username/password remain as a legacy fallback for qBit < 5.2. - QbitClient accepts `api_key`; a new `_auth_kwargs()` helper returns the Bearer header in key mode or the SID cookie in password mode, used at every authenticated request site. - refresh_cookie() and check_qbit_reachability() branch for key mode: login is skipped (qBit rejects /auth/login under key auth) and reachability probes /app/version with the Bearer header instead. A bad key or a <5.2 server both surface a clear tip and degrade instead of crashing. - If both api_key and username/password are set, the key wins (mirrors qBit), logged once at init. - Redact `Authorization` in sanitize_kwargs so the token never leaks in DEBUG logs. - Docs (config example, README) present api_key as recommended, creds as legacy. Tests cover header-vs-cookie selection, login skip, precedence, and the 403 degrade path.
lolimmlost
left a comment
lolimmlost
left a comment
There was a problem hiding this comment.
Clean implementation. The _auth_kwargs() abstraction is the right level of indirection -- encapsulates auth mode in one place and every request site just spreads it. Complete substitution of all 13 cookie call sites verified.
Key points:
- Key mode correctly skips /auth/login and probes /app/version instead; response = None safely bypasses the "Fails." password check via getattr guard
- Token redaction in sanitize_kwargs handles nested dicts (headers > Authorization) correctly
- Whitespace stripping on api_key prevents sending empty Bearer tokens
- Precedence (key wins over creds) matches qBit's own behavior
- Version guidance (701f67f) is guidance-only, no behavior changes -- warns on api_key + <5.2, recommends api_key on password + >=5.2, silent otherwise
- Test coverage is thorough across all auth paths, version guidance branches, degradation, and redaction
LGTM.
3 participants
Summary
Adds support for qBittorrent 5.2's stateless API key auth (
Authorization: Bearer <key>) and makes it the recommended way to connect. Username and password stay as a legacy fallback for qBit older than 5.2.Closes #353.
Behavior
api_keyon a qbittorrent client and decluttarr sendsAuthorization: Bearer <key>on every request. No login call, no session cookie.api_keyand username/password are set, the key wins (matching qBit's own precedence) and a one time info log notes the credentials are ignored.Security
Authorizationis added to the log redaction set, so the Bearer token is never written to debug logs.Also
check_connectednow includes the underlying error in its warning, so a key revoked at runtime surfaces the auth failure instead of a generic "disconnected" line.Testing