Auth_request and nested locations

Except for a few exceptions, I want to require authentication for an
entire site. The safest place would be to put the auth_request
directive at the http level but there’s no way to allow the
exceptions. If I put the auth_request in locations I’ll need to
repeat it multiple times and that seems less maintainable because the
chance of it getting missed when new services are added or changed. Is
there a decent way of structuring the config file for an auth portion
of a site and an un auth’d side?

Hello!

On Mon, Dec 10, 2012 at 10:35:00PM -0500, djczaski wrote:

Except for a few exceptions, I want to require authentication for an
entire site. The safest place would be to put the auth_request
directive at the http level but there’s no way to allow the
exceptions. If I put the auth_request in locations I’ll need to
repeat it multiple times and that seems less maintainable because the
chance of it getting missed when new services are added or changed. Is
there a decent way of structuring the config file for an auth portion
of a site and an un auth’d side?

There are two basic aproaches:

  1. Use “auth_request off” to switch off auth when needed:

    auth_request /auth;

    location / {

    }

    location /no_auth_here/ {
    auth_request off;
    }

  2. Use nested locations for places which need auth, and
    explicitly configure locations without auth when needed:

    location / {
    auth_request /auth;

     location /some_nested_location_with_auth/ {
         ...
     }
    

    }

    location /no_auth_here/ {
    # no auth_request here
    }


Maxim D.
http://nginx.com/support.html

Thank you for the reply.

On Tue, Dec 11, 2012 at 3:28 AM, Maxim D. [email protected]
wrote:

there a decent way of structuring the config file for an auth portion
}

location /no_auth_here/ {
    auth_request off;
}

I didn’t understand this was possible. I figured the auth_request
from the http level was “evaluated” first before looking at lower
levels. This is good to know.

location /no_auth_here/ {
    # no auth_request here
}

This style seems best, but I read a post from Igor that said you can
not use nested locations except with regular expressions:

http://forum.nginx.org/read.php?2,174517,174534#msg-174534

Maybe I am miss understanding his statement.

Thanks.

On 11 December 2012 11:52, djczaski [email protected] wrote:

This style seems best, but I read a post from Igor that said you can
not use nested locations except with regular expressions:

http://forum.nginx.org/read.php?2,174517,174534#msg-174534

Maybe I am miss understanding his statement.

Why don’t you try it out and see what happens?

I think Igor was speaking from a last-1%-performance perspective,
personally.

Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

On Tue, Dec 11, 2012 at 06:52:46AM -0500, djczaski wrote:

Hi there,

This style seems best, but I read a post from Igor that said you can
not use nested locations except with regular expressions:

http://forum.nginx.org/read.php?2,174517,174534#msg-174534

Maybe I am miss understanding his statement.

I suspect that the line

“”"
If you use only locations without regexes, then you may not use nested
locations.
“”"

is better understood as “you are not required to use nested” than “you
are required not to use nested”.

f

Francis D. [email protected]

On Dec 11, 2012, at 7:04 AM, Jonathan M. [email protected]
wrote:

On 11 December 2012 11:52, djczaski [email protected] wrote:

This style seems best, but I read a post from Igor that said you can
not use nested locations except with regular expressions:

http://forum.nginx.org/read.php?2,174517,174534#msg-174534

Maybe I am miss understanding his statement.

Why don’t you try it out and see what happens?

I did try it and it seems to work.

I think Igor was speaking from a last-1%-performance perspective, personally.

I kind of read it as “don’t do this” so i was concerned with using it as
a solution or hack.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs