Basic Authentication for Access rules is not working

[NovaViper]

Describe the bug Hey guys, I'm noticing that basic authentication isn't working on my instance at all. None of my reverse proxies are displaying the authentication dialog on any of my machines (tried on both my laptop and desktop, as well as my phone).

To Reproduce Steps to reproduce the behavior:

1. Create a reverse proxy rule
2. Add a Access Rule that uses a username+password
3. Link Access rule to proxy rule and restart nginx
4. Go the the reverse proxy, noticing that no authentication menu appears.

Expected behavior A authentication menu from the browser should be appearing

Screenshots If applicable, add screenshots to help explain your problem.

Operating System Raspberry pi 4 running Raspian Lite with OpenMediaVault installed, Nginx Proxy Manager is installed a docker container within Portainer.

Additional context Add any other context about the problem here, docker version, browser version if applicable to the problem. Too much info is better than too little. Nginx Proxy Manager version is v2.8.0

[andreas-barthel]

Have you tried to enable "Satisfy Any" in the Access List?

[NovaViper]

Have you tried to enable "Satisfy Any" in the Access List?

Yeah, it's still not working

[bpivk]

I have the same problem.

Details: Satisfy any enabled Authorization: Username/password set Access: Left default so ony deny all is filled at the bottom.

Changing all the settings hasn't changed anything.

[jtrosper]

Encountering the same exact issue here as described above.

[LouisAugry]

I have the same problem when I have custom location, without custom location it works.

[tmrtkn]

I also have this problem. With custom location authentication doesn't work, without it, it works.

[tmrtkn]

I'm not so sure about other cases, but my case seems to be that I am using / custom location path.

In https://github.com/jc21/nginx-proxy-manager/blob/master/backend/internal/nginx.js#L219 is a line "host.use_default_location = false;".

And then, in https://github.com/jc21/nginx-proxy-manager/blob/master/backend/templates/proxy_host.conf#L21, only the default location puts the authorization magic into the configuration file. If "use_default_location" is false, the authorization magic is omitted.

I am not a javascript expert by any means. Does this make any sense?

[tmrtkn]

Sorry about the spam. I probably found a workaround for my case. I added the following into custom location's custom configuration

# Authorization
auth_basic            "Authorization required";
auth_basic_user_file  /data/access/1;

proxy_set_header Authorization "";

# Access Rules
deny all;

# Access checks must...
satisfy any;

At least for me, that made the authentication dialog to appear. I hope that the configuration, as a whole, is still sane.

edit: I'm running npm in docker. version 2.8.0.
I have only 1 access list, hence 1 in auth_basic_user_file's value.

edit2: Force ssl by adding this into the configuration

# Force SSL
include conf.d/include/force-ssl.conf;

[MrColumbo]

I have the same issue. I am not quite sure how the custom location workaround is supposed to work. Do I need to put in a path? If I need to put in a path .....does it need to exist and what kind of files are expected at that path? I added a screenshot of my npm custom dialog:

[berengard]

I have a suspicion that it doesn't like symbols in the password. After making a new access list for the 4th time, I gave it a password with only alphanumeric characters, then I assigned the access list to the host and it worked. Before that it was showing me the authentication dialog sometimes but never accepting the password. And at one point it was working in firefox, but not in chrome, which is totally weird! :/

[randomparity]

Having the same problem. If I generate a password from the command-line with htpasswd and insert the result into the access file with a text editor then I'm able to use a password with special characters:

# htpasswd -n admin
New password:
Re-type new password:
admin:$apr1$pAaFZMwI$w8D5AjloujDli./NIX5MK1

[speakradmin]

Ran into this same problem running 2.10.4. Hope the dev can check it out

[speakradmin]

Ok scratch that. I was doing this on an older verion.

Fresh install of 2.10.4 getting forbidden with no prompt on any host with a basic auth access list but the fix from @randomparity doesn't work. IP based still works fine.

Tested in incognito as well to make sure there wasn't some browser cache interfering

[github-actions[bot]]

Issue is now considered stale. If you want to keep it open, please comment :+1: