Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#559 closed enhancement (wontfix)

improvement proposed for ngx_http_auth_request_module

Reported by: David Coutadeur Owned by:
Priority: minor Milestone:
Component: nginx-module Version: 1.5.x
Keywords: Cc:
uname -a: Linux debian-wheezy-64-lemon 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.6.0
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,-z,relro --prefix=/opt/nginx --http-log-path=/var/log/nginx16/access.log --error-log-path=/var/log/nginx16/error.log --lock-path=/var/lock/nginx16.lock --pid-path=/run/nginx16.pid --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_spdy_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module

Description

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 ?

Attachments (2)

ngx_http_auth_request_module.c.patch (784 bytes ) - added by David Coutadeur 6 years ago.
patch
ngx_http_authn_request_module.c (11.5 KB ) - added by David Coutadeur 6 years ago.
new nginx authentication request module -----------------------------110164748276940691108114960 Content-Disposition: form-data; name="replace" on

Download all attachments as: .zip

Change History (7)

by David Coutadeur, 6 years ago

patch

comment:1 by Maxim Dounin, 6 years ago

Resolution: wontfix
Status: newclosed

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

comment:2 by David Coutadeur, 6 years ago

Sorry but my use case really needs two defined different behaviours 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.

Last edited 6 years ago by David Coutadeur (previous) (diff)

comment:3 by Maxim Dounin, 6 years ago

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.

comment:4 by David Coutadeur, 6 years ago

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 !

by David Coutadeur, 6 years ago

new nginx authentication request module


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

on

in reply to:  4 comment:5 by Maxim Dounin, 6 years ago

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:

  1. 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.

Note: See TracTickets for help on using tickets.