improvement proposed for ngx_http_auth_request_module

[David Coutadeur]

Hi all,

I propose a nice functionnality which is to provide redirection with the ngx_http_auth_request_module.
Ie if the subrequest sends a redirect, then the auth_request will get the redirection and send it to the user.

Here is the patch:

--- ngx_http_auth_request_module.c 2014-05-16 18:36:04.312203467 +0200
+++ ngx_http_auth_request_module.c.patch 2014-05-16 18:35:39.004204963 +0200
@@ -138,6 +138,22 @@

return ctx->status;

}

+ /* case redirect */
+ if (ctx->status == NGX_HTTP_MOVED_TEMPORARILY) {
+ sr = ctx->subrequest;
+ h = sr->headers_out.location;
+ if (h) {
+ ho = ngx_list_push(&r->headers_out.headers);
+ if (ho == NULL) {
+ return NGX_ERROR;
+ }
+
+ *ho = *h;
+ r->headers_out.location = ho;
+ }
+ return ctx->status;
+ }
+

if (ctx->status == NGX_HTTP_UNAUTHORIZED) {

sr = ctx->subrequest;

Just a warn: the location field from the subrequest does not seem to be taken into account... Maybe somebody can see why ?

[David Coutadeur]

patch

[Maxim Dounin]

If needed (and possible in a particular configuration), this can be done by defining error_page 403 with additional processing.

[David Coutadeur]

Sorry but my use case really needs two defined different behaviour for error code 403 and 302.
And I think some other people may enjoy this functionnality. Could you give a chance to my patch ?

Thank you in advance for your consideration.

[Maxim Dounin]

There is nothing to stop from conditional processing in error page 403, providing as many behaviours as needed. Additionally, suggested code is wrong as it doesn't play well with ​satisfy any.

[David Coutadeur]

Hi,

What I would like to have is these 3 behaviours:

• auth_request returns 200, let the request pass,
• auth_request returns 302, then let it pass, with the given Location header set, so that redirection happens,
• auth_request returns 403, then block with a forbidden page, which can be intercepted by an error_page 403 to do some more other things...

1. I don't see how I could do this with just a 403 ? If I am wrong, can you give me an example ?
2. Because of my example complexity, it seems nicer or cleaner to implement these 3 behaviours natively, isn't it ?

Concerning the satisfy any, I understand your point of view.
As I use my auth_request much like an authentication request than an "authorization", I propose the following (attached file) "new" module authn_request, completely inspired from auth_request.
It is independant from auth_request, and defines two directives authn_request and authn_request_set.
I have successfully integrated it in nginx, and it works well.
Can you consider it ?

Thanks in advance for you valuable time and help !

[David Coutadeur]

new nginx authentication request module

---

Content-Disposition: form-data; name="replace"

on

[Maxim Dounin]

Replying to David Coutadeur <david.coutadeur@gmail.com>:

Hi,

What I would like to have is these 3 behaviours:

• auth_request returns 200, let the request pass,
• auth_request returns 302, then let it pass, with the given Location header set, so that redirection happens,
• auth_request returns 403, then block with a forbidden page, which can be intercepted by an error_page 403 to do some more other things...

1. I don't see how I could do this with just a 403 ? If I am wrong, can you give me an example ?

As long as your auth script can return 403 instead, providing additional information though a response header (e.g., 'Location'), something like this should work:

    location / {
        auth_request /auth;
        auth_request_set $location $upstream_http_location;
        error_page 403 = /403;
        ...
    }

    location /403 {
        if ($location) {
            return 302 $location;
        }

        return 403;
    }

    location /auth {
        ...
    }

It is left as an exercise for the reader to write a configuration which will work if the auth script returns 302 and can't be modified.

See the following links for more details:

• ​http://nginx.org/r/error_page
• ​http://nginx.org/r/auth_request
• ​http://nginx.org/r/auth_request_set
• ​http://nginx.org/r/proxy_intercept_errors

2. Because of my example complexity, it seems nicer or cleaner to implement these 3 behaviours natively, isn't it ?

It doesn't looks like commonly required behaviour. If it is needed in your use case, it can be implemented using a simple configuration snippet above.

Concerning the satisfy any, I understand your point of view.
As I use my auth_request much like an authentication request than an "authorization", I propose the following (attached file) "new" module authn_request, completely inspired from auth_request.
It is independant from auth_request, and defines two directives authn_request and authn_request_set.
I have successfully integrated it in nginx, and it works well.
Can you consider it ?

The "module" suggested has the same problem: it doesn't interact with other access phase modules properly. On the other hand, nobody stops you from maintaining your own fork of the module with any modifications you want.