auth_request off; ignored when combined with auth_basic;

Stian Øvrevåge sovrevage at gmail.com
Fri Oct 13 16:39:50 UTC 2017


Quick follow-up. I tried negating the 401 redirect at the /api/
endpoint but got an error:

      named location "@error401" can be on the server level only

Any suggestion on how I can enforce a side-wide redirect to /security/
except the 2-3 endpoints that have basic auth?

Br,
Stian

On 13 October 2017 at 11:14, Stian Øvrevåge <sovrevage at gmail.com> wrote:
> Thanks a bunch. When still being redirected now I found the culprit:
>
>        location @error401 {
>            return 302 /security/;
>        }
>
> Which of course will redirect before auth basic will work.
>
> Thanks again and pardon my ignorance :o
>
> Br,
> Stian
>
> On 13 October 2017 at 04:14, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> Hello!
>>
>> On Fri, Oct 13, 2017 at 12:47:11AM -0500, Stian Øvrevåge wrote:
>>
>>> Hi list,
>>>
>>> I have a server {} block that is protected with auth_request; on the top level.
>>>
>>> auth_request is used for a interactive login process.
>>>
>>> I have some endpoints that will receive data from other software, and
>>> must instead be protected by auth_basic. However, "auth_request off;"
>>> is ignored in these location{} blocks IF there is also a auth_basic
>>> statement in the block.
>>>
>>> This works without logging in:
>>>        location /test/ {
>>>           auth_request off;
>>>           proxy_pass http://localhost:88/;
>>>        }
>>>
>>> This is automatically redirected back to /security/ for login (as
>>> defined by auth_request in server{} block.
>>>        location /api/ {
>>>           auth_request "off";
>>>           auth_basic "Restricted access";
>>>           auth_basic_user_file /etc/htpasswd;
>>>           proxy_pass http://localhost:88/;
>>>        }
>>>
>>> I see online references to a "satisfy any" directive that apparently
>>> worked a few years ago, but it does not anymore, and others are
>>> reporting similar problems:
>>> https://stackoverflow.com/questions/42301559/nginx-with-auth-request-and-auth-basic
>>
>> Works fine here:
>>
>> $ curl http://127.0.0.1:8080/
>> <html>
>> <head><title>403 Forbidden</title></head>
>> <body bgcolor="white">
>> <center><h1>403 Forbidden</h1></center>
>> <hr><center>nginx/1.13.7</center>
>> </body>
>> </html>
>> $ curl http://127.0.0.1:8080/test/
>> ok
>> $ curl http://127.0.0.1:8080/api/
>> <html>
>> <head><title>401 Authorization Required</title></head>
>> <body bgcolor="white">
>> <center><h1>401 Authorization Required</h1></center>
>> <hr><center>nginx/1.13.7</center>
>> </body>
>> </html>
>> $ curl --basic --user foo:foo http://127.0.0.1:8080/api/
>> ok
>>
>> Just tested with the following configuration:
>>
>>     server {
>>         listen 8080
>>
>>         auth_request /auth;
>>
>>         location / {
>>             proxy_pass http://localhost:8082;
>>         }
>>
>>         location /test/ {
>>            auth_request off;
>>            proxy_pass http://localhost:8082;
>>         }
>>
>>         location /api/ {
>>            auth_request "off";
>>            auth_basic "Restricted access";
>>            auth_basic_user_file /path/to/htpasswd;
>>            proxy_pass http://localhost:8082;
>>         }
>>
>>         location = /auth {
>>             return 403;
>>         }
>>     }
>>
>>     server {
>>         listen 8082;
>>         return 200 ok\n;
>>     }
>>
>> Note that in the request to /api/, where auth_basic is configured,
>> you have to request specify username and password, or the request
>> will be rejected by auth_basic.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx


More information about the nginx mailing list