search

tumblfeed / nzbunity

Adds the ability to send and control Usenet NZB files from various sites to SABnzbd+ or NZBGet download clients.
Mozilla Public License 2.0
44 stars 8 forks source link

HTTP basic auth not working #54

Open chron-isch opened 3 years ago

chron-isch commented 3 years ago

Hi,

my SABnzbd is running behind a nginx reverse proxy with http basic auth. NZB Unity stops working and is unable to establish a connection to my server with URLs like https://USER:PASSWORD@server/sabnzbd/, as soon a I disable basic auth and switch the URL to https://server/sabnzbd/ it works flawlessly.

Strangely enough, doing the same thing with Chromium, works without a problem.

Tested with:

pke commented 2 years ago

Same here. The username password fields in options are grayed out too. Not sure what they are there for but basic auth is not working.

clutterskull commented 2 years ago

Weird, I'll give it a look. The basic auth settings in config are for NZBGet (which uses its own implementation), I don't know that I ever specifically implemented basic auth for sab. Might be able to reuse those settings. Have you tried with both "Use host URL exactly as entered" checked / unchecked?

I may miraculously have some free time this weekend to have a look; I haven't had a lot of time for non-work dev recently.

clutterskull commented 2 years ago

(it only expects to use an API key for SAB, but it's possible I could add an optional basic auth to the request)

pke commented 2 years ago

Thanks, I have another chrome extension installed "sabnzbd" and when I added the basic auth informations there, then it also started to work in nzbunity. Do extensions share domain cookies or cached basic authentication?

clutterskull commented 2 years ago

It makes a separate http request. I could probably have it use cookies now that you mention it.

clutterskull commented 2 years ago

Side note, I mention the "Use host URL" option as that was specifically added to address problems connecting to reverse proxy'd SAB installs

clutterskull commented 2 years ago

Ok, I've looked into it a little and what I can do is check for "USERNAME:PASSWORD@..." in the host url and make sure those are sent as basic http auth with the request if it's not working from just the host field.

@chron-isch @pke Did the "Use host URL exactly as entered" work for either of you using the https://USER:PASSWORD@server/sabnzbd/ URL pattern?

*edit: looking at it now, it's likely the username and password is being parsed right out of the url when the request is made. I'll try a fix this evening.

clutterskull commented 2 years ago

Just released 1.15.5, which has the fix I proposed above. Google is reviewing the update, usually it goes out within a couple hours.

In the Host setting for your profile, use the "username:password@" format and it should pass it through to all requests. You will still need an API key as normal for SAB. Please let me know if this works / doesn't work.

pke commented 2 years ago

Thanks. Will try it out.

pke commented 2 years ago

Since my password contains @ I cant use this notation. The parsing gets disturbed by it and the credentials extracted from the URL are invalid then.

Whats the reason not to use the username password fields in the options dialog?

clutterskull commented 2 years ago

My first comment mentions it, but your average SABnzbd setup does not use username and password, only API key. Conversely, NZBGet uses usernames / passwords for everything, but does not have API keys.

All fields are shown for both profiles so that the profile UI does not change size, but probably should have just hidden them anyway.

To answer why I don't just enable them, it's to reduce confusion as to what is required for a given profile, but I could probably apply some wording or something. Sending username and password in the headers is preferable from a security standpoint anyway.

But, before I go in there and start making a bunch of changes (it's not just the input fields, they aren't hooked up to anything in the SAB client class), can you try substituting %40 for @ in your password in the url?

chron-isch commented 2 years ago

Sorry for the extremely late reply... I just tested with 1.17.0 on Firefox and it's still having the same problem.