bogenpirat / remote-torrent-adder

A handy Chrome extension to add torrent files to torrent clients
237 stars 80 forks source link

qbitorrent error 401 when trying to add torrent #326

Open xxtensazenxx opened 2 years ago

xxtensazenxx commented 2 years ago

image This program worked fine when I was using it with RTorrent, but I switched to QBT and now I'm having issues. I have tried so many options and configs. Its to the point where it give me the url and error 401, but if I go to that URL its valid and asks for me login. Not sure how to fix. I am using a reverse NGINX proxy too.

I can provide more info if needed

bogenpirat commented 2 years ago

couple of points.

  1. what version of qbt? the more recent versions require you to use the qbt-v2 client in the options.
  2. the QBT code currently doesn't support sub-paths in the server address. it's likely that you're using those if you use reverse proxy via nginx. cf. with the first handful of lines here.
  3. a way to circumvent 2. is to pull a sneaky one on the port setting and append "/qbittorrent" to it. that's dumb, but it should work.
n-i-x commented 2 years ago

I have the same problem. I'm also using a reverse NGINX proxy (linuxserver.io/qbittorrent). I don't believe the reverse proxy is the issue as the API works otherwise.

This extension cannot login, yet I am able to easily login using curl to craft a post message:

NGINX logs:

Manual request:

[05/Aug/2022:00:48:26 -0400] "POST /api/v2/auth/login HTTP/2.0" 200 3 Request URI: "/api/v2/auth/login" URI: "/api/v2/auth/login" Session: "-" Body: "username=user&password=password" Request ID: "2c2be9ffc528dcd37aef99e6f66706a5"

Extension:

[05/Aug/2022:00:48:41 -0400] "POST /api/v2/auth/login HTTP/2.0" 401 12 Request URI: "/api/v2/auth/login" URI: "/api/v2/auth/login" Session: "-" Body: "username=user&password=password" Request ID: "c51513d913c2aedf2c70fe597061269e"

Here's the full response from the server when it works. I don't know how to do the same with the extension.

$ curl -v 'https://myhost.com/api/v2/auth/login' --data-urlencode 'username=user' --data-urlencode 'password=password'
> POST /api/v2/auth/login HTTP/2
> Host: myhost.com
> user-agent: curl/7.68.0
> accept: */*
> content-length: 36
> content-type: application/x-www-form-urlencoded
>
< HTTP/2 200
< server: nginx/1.20.2
< date: Fri, 05 Aug 2022 05:00:14 GMT
< content-type: text/plain; charset=UTF-8
< content-length: 3
< content-security-policy: default-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; script-src 'self' 'unsafe-inline'; object-src 'none'; form-action 'self'; frame-ancestors 'self';
< referrer-policy: same-origin
< set-cookie: SID=1TTOkMz+2BSu8x9kRK58jXTRrpdJeDCS; HttpOnly; path=/; SameSite=Strict
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< strict-transport-security: max-age=2592000; includeSubDomains; preload
<
* Connection #0 to host myhost.com left intact
Ok.

I'm using qBittorrent v4.4.3.1 Web UI (64-bit)

bogenpirat commented 2 years ago

those requests look identical to me. weird. just updated to that same qbt version locally and the extension seems to have no issue with it.

Here's the full response from the server when it works. I don't know how to do the same with the extension.

in a new tab, you go to chrome://extensions/?id=oabphaconndgibllomdcjbfdghcmenci, enable the developer mode to the top right, then click on "background page" under "inspect views", and then click on the network tab. with that open, you can click on a torrent and it should display the request, complete with headers and everything.

perhaps that can shed light on the issue; since the requests look identical (and i assume you made doubly-sure to enter the right credentials), i kinda expect the reverse proxy to somehow be at fault. but let's see.