qBittorrent
qBittorrent copied to clipboard
qbittorrent
Getting a 403 Status Code when Calling `api/v2/app/webapiVersion`
qBittorrent version and Operating System
qBittorent 4.3.3, macOS 11.2.2 (Intel)
What is the problem
via pymedusa when the call /api/v2/app/webapiVersion is made I get Error: HTTPError('403 Client Error: Forbidden
this issue only occurs for downloads that have a set category & have been pushed by pymedusa.
when the application makes a call to check on the seeding/downloading status of the torrent it gets that error. all other requests work fine
I'm not a developer of this software as I just use it, i was asked to raise the issue here as this is most likely an issue with qbittorrent as it cannot handle the request to /api/v2/app/webapiVersion when also trying to check the seeding status on an active torrent with a set category.
I feel the issue is an authentication issue? when checking for torrent status & right after checking for webapiVersion it fails to authenticate?
What is the expected behavior
to not get a 403 response code
Steps to reproduce
using pymedusa, have download handler setup & qbirtorrent integrated (User & Pass), then manual snatch any episode via medusa & force downed handler to run to check the torrent status & you get that error
Extra info(if any)
the issue does not occur if running /api/v2/app/webapiVersion on its own without having a torrent to check...
Error Code:
2021-03-07 04:11:01 DEBUG DOWNLOADHANDLER :: [90f913f] The response returned a non-200 response while requesting url http://localhost:8082/api/v2/app/webapiVersion Error: HTTPError('403 Client Error: Forbidden for url: http://localhost:8082/api/v2/app/webapiVersion')
2021-03-07 04:11:01 ERROR DOWNLOADHANDLER :: [90f913f] qBittorrent: Unable to get API version. Error: ValueError('Response from client is empty. [Status: 403]')
the Download Manager: https://github.com/pymedusa/Medusa (manages tv shows) the qbittorent specific client integration for pymedisa: https://github.com/pymedusa/Medusa/blob/master/medusa/clients/torrent/qbittorrent.py | issue occurs on line 63
What's the issue here is that there is an application state where the request to /webapiVersion will not return the SID cookie.
What made this apparent is that In user space we tried to set the SID cookie on every call. And if no cookie is returned, we removed the previously set SID cookie from the client session.
So partially we resolved this issue in pyMedusa, by not cleaning an existing set SID cookie, when no cookie is returned on /webapiVersion.
But unfortunately that still means that there is some weird stuff going on in qbittorrent, where under certain circumstances it's not returning the SID.
Why didn't you report it to Medusa instead? It looks like it's just executing an unauthorized request. The current qBittorrent web API does not allow any requests from non-authenticated users, including requests for version.
The request is always properly authenticated. Content-Type is application/x-www-form-urlencoded with username/password params passed. If we'd failed to auth, it would fail at all times. But that's not the case. It's pretty much always authenticating. Except for when qbittorrent is in the process of adding/starting a torrent download. Or finishing it like 99%/100%.
@qbittorrent/bug-handlers Can someone understand what is said in https://github.com/qbittorrent/qBittorrent/issues/14497#issuecomment-792238807? Sounds pointless to me. SID must be set for any response regardless of the request endpoint during the lifetime of the session.
Took me sometimes but i figured it out.
It seems that sometimes /login doesn't return the SID cookie.
To work around the problem they now use the last valid SID instead of using the one just returned (possibly missing).
In fact, i found a possible scenario where /login doesn't return the SID cookie.
@glassez found the problem, if you login passing an already valid SID, no SID will be returned.
@glassez found the problem, if you login passing an already valid SID, no SID will be returned.
What's the problem? login does nothing if user is logged in currently.
It can lead to this type of problem, where login "succeeds" but it doesn't return the SID and it is handled as failed by the caller. Another problem: if you login using invalid credentials while sending a valid SID, the login will succeds.
A login request for an already logged in user is at least meaningless. So we can even consider such requests as invalid and reject them.
did anyone manage to bypass the forbidden 403? Im trying to get up / down speed by API to Homer dashboard, and i get the same message.
