search

bogenpirat / remote-torrent-adder

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

webui login not working #311

Closed wamaisi closed 3 years ago

wamaisi commented 3 years ago

The WebUI login seems broken. Input my WebUI username and password but it does not log in at all, tried a wrong username / password it don't show error login info alert too

bogenpirat commented 3 years ago

Did it break only recently, or is it possible that your configuration is incorrect? What torrent client are you using? Is the web ui of that client working fine when you log in manually in a browser tab?

wamaisi commented 3 years ago

Am using qBittorent jail in truenas core. Can't tell when it started, was using whitelisted IP option for ~6 months. Updated the jail 2 month+ ago and this week reverted to webui login without IP whitelist, thats when I found out RTA webui login feature not working.

The jail running qBittorent version 4.3.7 64bit

bogenpirat commented 3 years ago

i guess you could go to chrome://extensions/?id=oabphaconndgibllomdcjbfdghcmenci, enable the developer mode in the top right and then inspect the background page view, go to network and try to click on a torrent. that should give you some more information on what exactly goes wrong. feel free to share some (redacted) info if you feel it's an RTA issue as opposed to something in terms of configuration.

csjoh commented 3 years ago

I'd just like to chime in and say that RTA is unable to log into my qBittorrent 4.3.8 webui. Error message on what should be the client page is just "Unauthorized". Entering the URL to the webui and logging in manually works fine.

There is nothing in the developer console that indicates configuration error on qB's part, RTA just doesn't pass the credentials along, it seems.

bogenpirat commented 3 years ago

i upgraded to qBt 4.3.8 on my test bed and RTA adds torrents out of the box just fine.

There is nothing in the developer console that indicates configuration error on qB's part, RTA just doesn't pass the credentials along, it seems.

would be useful to have a look at that.

here's a screenshot of the request my RTA sends to my local qBt: image

note that if you want to share your network request, you should censor your login credentials at the bottom.

even got all the qBt security settings enabled: image

csjoh commented 3 years ago

Hi and thanks for reaching out.

I should probably mention that I’m running qBittorrent in a docker container on my server and not locally installed on my computer, but that shouldn’t really make that much of a difference. I’m also using Vivaldi which is based on Chromuim and thus should be more or less the same as Chrome/Chromium, but the result is exactly the same in Chrome.

Here’s my devconsole snip:

image

As you can see, there are no credentials being sent.

And my qBittorrent security settings:

image

bogenpirat commented 3 years ago

that looks like the wrong request. compare your request URL (first line) to mine - it's missing the entire path. RTA wouldn't attempt to access just the domain (i'm guessing) by itself without attempting to, on the qBt v4.1+ setting, either

  1. logging in under /api/v2/auth/login, or
  2. adding a torrent under /api/v2/torrents/add.

are you sure you've taken this screenshot from the dev tools opened from the extension dialog in chrome here? image

csjoh commented 3 years ago

Okay, quick update.

After googling a bit about this and messing with the security settings, I found I had to deactivate CSRF protection and Host header validation in order to get it to work.

I also failed to mention in my previous post that I'm running my qBittorrent container behind a reverse proxy that handles SSL for the services hosted on the server.

I'll have a look at the reverse proxy and see if there is a way to reenable CSRF and Host Header validation and have NGINX play nice with RTA.

Sorry about the noise, but at least a few points to consider.

csjoh commented 3 years ago

that looks like the wrong request. compare your request URL (first line) to mine - it's missing the entire path. RTA wouldn't attempt to access just the domain (i'm guessing) by itself without attempting to, on the qBt v4.1+ setting, either

  1. logging in under /api/v2/auth/login, or
  2. adding a torrent under /api/v2/torrents/add.

are you sure you've taken this screenshot from the dev tools opened from the extension dialog in chrome here? image

If I open the dev tools from that page, I get nothing that looks like the screenshot you first posted. I tried clicking the background page link and dev tool that, but that doesn't give me any requests going to my server either.

It's a bit late and I'm tired, so maybe it's just me not seeing what I'm supposed to. In any case, as I wrote in my previous entry, I did get it working by disabling CSRF protection and Host Header validation, so it "works for now" and I'll look into NGINX options for those two things and post back if I figure out a solution.

bogenpirat commented 3 years ago

I also failed to mention in my previous post that I'm running my qBittorrent container behind a reverse proxy that handles SSL for the services hosted on the server.

CSRF protection is just for form validation of the web interface's forms. since qBt has a full API, you shouldn't need to disable it for RTA to work.

host header validation however is probably what's breaking your neck. you could try entering your domain in qBt's server domains. but unless your reverse proxy also alters the Origin and Referer header fields of requests delivered to qBt, it shouldn't be working even for you manually in the browser.

If I open the dev tools from that page, I get nothing that looks like the screenshot you first posted. I tried clicking the background page link and dev tool that, but that doesn't give me any requests going to my server either.

it'll only display network requests sent after you open the dev tools. so

  1. open dev tools
  2. go to network tab
  3. try to add a torrent in another tab via RTA
  4. check dev tools