Proxy Host Custom Locations do not apply Access Lists

[sadowski]

I expect that if I apply an Access List to a Proxy Host, and then add a Custom Location to a proxy host, that when I go to that location for the first time, I am asked to supply authorization. This does not happen. The Custom Location is accessible without a username and password.

To reproduce:

1. Create an Access List with a user and password
2. Create a Proxy Host
3. Add the Access List to the Proxy host
4. Add a Custom Location
5. Save
6. Go to the custom location

Expected Result:
You are asked to supply username and password via basic auth.

Actual Result:
The page loads without authorization.

[jc21]

ahh yeah definitely an oversight

[emko]

can we enable the auth in custom ngix configuration?

[meiskam]

It'd be nice to have Access List box show up for each custom location, so I can have a custom location with a password and the main bit without one

[jValdron]

@meiskam, just add the following to your custom location "advanced options":

auth_basic            "Authorization required";
auth_basic_user_file  /data/access/{{ access_list_id }};

Taken from the proxy_host.conf template: https://github.com/jc21/nginx-proxy-manager/blob/master/src/backend/templates/proxy_host.conf

[jgearinger]

still an issue... creates a pretty big security hole if you do not test specifically for this issue.

[ahknight]

I just ran into this as I wanted different levels of access for different apps on a domain. It’s also not easy to find out the ACL ID remotely (VPN, browser only) so I had to go guessing. It’d be nice to have a menu for each custom location to pick the ACL for it and have it just insert that blob.

[wtf911]

Would also like to see this fixed please!

[clb92]

This is actually a pretty big issue for me, that locations don't inherit the host's access control.

I can't even get the solution above (adding auth_basic and auth_basic_user_file to the custom location) to work correctly:

If I use same access list on both host and location

My host subdomain.domain.com goes to one web server. It has access list 0 added to it through the dropdown list selector.

My custom location /subdir goes to another web server. It also has access list 0 added, by the two lines in the custom location config.

If I visit subdomain.domain.com/ and authenticate, that site displays fine, but if I then go to /subdir/, I always get 403 Forbidden.

If I visit subdomain.domain.com/subdir/ directly (without authenticating on subdomain.domain.com/ first), it will ask me to authenticate, but then I still get 403 Forbidden on, no matter what I do.

If I use different access lists on host and location it works

My host subdomain.domain.com still has access list 0 added to it.

But now, custom location /subdir has access list 1 added instead.

Now it works more as expected. Navigating to subdomain.domain.com asks for auth, and then going to subdomain.domain.com/subdir/ also asks for auth (but different credentials).

Navigating between the pages, it will keep asking for auth, since you can apparently only be authenticated with one set of credentials on one domain. This is expected.

The problem?

Studying the Docker container log, I see this line when I save the proxy settings through the GUI:

Duplicate relation "access_list" in a relation expression. You should use "a.[b, c]" instead of "[a.b, a.c]". This will cause an error in objection 2.0

No idea if it's related.

So, is it just a bug in NPM that a host and a location (on that same host) can't use the same access list?

If anyone knows how to fix this, please let me know.

EDIT: For now, I can have the same access list on the host and location by actually making another access list (with same list of credentials in it) and using one list on the host, and the clone on the location. Works for now, but it's a terrible solution.

[colonelmattyman]

Websockets on Custom Domains are also broken because of this. I really think that this bug needs some urgent attention and a fast resolution. It's been open since 23 May 2019.

[Tezzlicious]

Must agree. Issue needs an urgent fix or needs to be mentioned on the homepage. Thanks for the efforts.

[colonelmattyman]

I ended up rolling back to V1.5.0 to fix it.