[PATCH] Allow http_auth_request_module to forward 302 responses

[Maxim Dounin]

Hello!

On Sat, Feb 18, 2012 at 06:48:50PM -0500, Maxim Khitrov wrote:

> On Sat, Feb 18, 2012 at 4:45 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > Hello!
> >
> > On Sat, Feb 18, 2012 at 09:19:18AM -0500, Maxim Khitrov wrote:
> >
> >> Hello Maxim,
> >>
> >> The attached patch allows your http_auth_request_module to forward a
> >> 302 response and the associated "Location" header to the client. The
> >> goal is to allow the authentication back end to redirect the client to
> >> a login page instead of using WWW-Authenticate header.
> >
> > You may get the same result by returning 401/403 and using
> > appropriate error_page handler.  I don't actually see a reason to
> > handle 302 specially here.
> 
> Allow me to clarify. I cannot use 401/403 codes, because I need both
> of those to perform their original function. 403 has to block access
> without redirecting anywhere and 401 must be used to pass the
> WWW-Authenticate header.

Actually you can.  You just need to use some additional processing 
inside error_page handler (or two different error_page handlers, 
selected based on auth request answer), e.g.

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

    location = /auth {
        proxy_pass http://auth_backend;
        ...
    }

    location = /auth_403 {
        if ($auth_redirect) {
            return 302 $auth_redirect;
        }

        return 403;
    }

And then either set Location (or some other arbitrary header) in a 
403 response or not.

[...]

> Even without this scheme, I think allowing the use of a 302 response
> would be a useful feature. Relying on the error_page configuration,
> which I did consider before making my patch, increases the complexity
> of nginx.conf and could lead to unintended behavior. This way, a
> single "auth_request /auth;" line takes care of all possible decisions
> (authenticate/allow/deny/redirect).

I believe the problem here is how one define "all possible 
decisions".  And I'm really sure that if 302 will be allowed - 303 
and 307 will appear next to it, and then we'll start discussing 
which headers should be passed - e.g. Set-Cookie looks like 
something required in addition to Location.  That's why I 
(intentionally) limited it to only handle 401/403, much like 
normal auth_basic.

I think correct aproach for the future would be to implement some 
"transparent" mode, much like fastcgi authorizers, where one may 
return arbitrary answer with any headers and body while rejecting 
request.  This is not something trivial to implement as of now 
though, mostly because of body.

Maxim Dounin