# Enforcing authentication requests for all resources under specific path

**URL:** <https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368>\
**Category:** NGINX\
**Created:** [March 29, 2012, 4:33pm UTC](https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368 "2012-03-29T16:33:16Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [March 29, 2012, 4:33pm UTC](https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368/1 "2012-03-29T16:33:16Z")

</div>

Hi,

I’m working on an application independent authentication and  
authorization layer that utilizes nginx with auth request module. The  
two are working great for me, but I run into an issue that I don’t  
know how to solve, maybe you can help?

Is there a way to enforce auth requests for all resources under a  
specific path? Say I want to protect all resources in /protected:

location /protected/ {  
auth\_request /auth/is\_authenticated/;  
error\_page 403 /auth/login/;  
error\_page 401 /auth/noauthorized/;  
}

This works but only until more specific location is added:

location /protected/blog {  
#…  
}

Which, due to location matching rules, takes precedence over the  
‘/protected’ location, and auth requests for blog are not issued.

Is there any way around it other than repeating auth\_request  
configuration for each location?

I can think of two solutions, but each has quite substantial  
limitations:

1. configure auth\_request in server {} section, but this authorizes  
all requests, not only ones in ‘/protected’
2. Run separate nginx instance configured to do authorization only and  
passing all allowed requests downstream. This would introduce  
additional performance and maintenance overhead.

Is there any better way?

thanks,  
Jan

---

<div class="post-metadata">

**Author:** ![Jan\_Wrobel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7feea3/32.png) [@Jan\_Wrobel](https://www.ruby-forum.com/u/Jan_Wrobel)\
**Post date:** [March 29, 2012, 4:45pm UTC](https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368/2 "2012-03-29T16:45:03Z")

</div>

On Thu, Mar 29, 2012 at 04:32:32PM +0200, Jan Wrobel wrote:

> location /protected/ {
> 
> passing all allowed requests downstream. This would introduce  
> additional performance and maintenance overhead.
> 
> Is there any better way?

I believe the best way to configure is to set explicitly necessery  
directives in all locations where they are required. This leads to  
maintainable configuration.

–  
Igor S.

---

<div class="post-metadata">

**Author:** ![Jan\_Wrobel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7feea3/32.png) [@Jan\_Wrobel](https://www.ruby-forum.com/u/Jan_Wrobel)\
**Post date:** [March 29, 2012, 7:21pm UTC](https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368/3 "2012-03-29T19:21:38Z")

</div>

On Thu, Mar 29, 2012 at 4:44 PM, Igor S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> On Thu, Mar 29, 2012 at 04:32:32PM +0200, Jan Wrobel wrote:
> 
> > Is there any better way?
> 
> I believe the best way to configure is to set explicitly necessery  
> directives in all locations where they are required. This leads to  
> maintainable configuration.

In my case this is not too good option. I need authentication layer  
configuration to be independent from applications configuration. In  
case of authentication (not only auth request but also auth basic)  
repeating configuration for each location, without ‘catch them all’  
rule could lead to holes that are hard to notice. For example if I  
configure authentication correctly for blog/_html but forget to do it  
for blog/_.png the mistake will likely be unnoticed 😕

Anyway, if there are no other options, I’ll try using auth\_request in  
server{} section.

Thanks,  
Jan

---

<div class="post-metadata">

**Author:** ![Jan\_Wrobel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7feea3/32.png) [@Jan\_Wrobel](https://www.ruby-forum.com/u/Jan_Wrobel)\
**Post date:** [March 29, 2012, 10:29pm UTC](https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368/4 "2012-03-29T22:29:54Z")

</div>

On Thu, Mar 29, 2012 at 07:21:05PM +0200, Jan Wrobel wrote:

Hi there,

> In my case this is not too good option. I need authentication layer  
> configuration to be independent from applications configuration. In

Because of the way nginx configuration works, they can’t be completely  
independent.

But you could try nesting locations:

location /protected/ {  
auth\_request etc…

location /protected/blog {  
blog config…  
}

location ~ png {  
png config…  
}

}

(And of course you’ll want no top-level regex locations; but that’s good  
practice anyway.)

Quick testing suggests that the auth request module does inherit these  
configurations.

## f

Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![Jan\_Wrobel](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7feea3/32.png) [@Jan\_Wrobel](https://www.ruby-forum.com/u/Jan_Wrobel)\
**Post date:** [March 29, 2012, 10:53pm UTC](https://www.ruby-forum.com/t/enforcing-authentication-requests-for-all-resources-under-specific-path/218368/5 "2012-03-29T22:53:35Z")

</div>

On Thu, Mar 29, 2012 at 10:29 PM, Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> But you could try nesting locations:  
> }
> 
> }
> 
> (And of course you’ll want no top-level regex locations; but that’s good  
> practice anyway.)
> 
> Quick testing suggests that the auth request module does inherit these  
> configurations.

Thanks, this works!

Jan