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@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

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel