Welcome! Log In Create A New Profile

Advanced

Re: [PATCH] Allow http_auth_request_module to forward 302 responses

Maxim Dounin
February 18, 2012 11:02PM
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
Subject Author Views Posted

[PATCH] Allow http_auth_request_module to forward 302 responses Attachments

Maxim Khitrov 1252 February 18, 2012 09:20AM

Re: [PATCH] Allow http_auth_request_module to forward 302 responses

Maxim Dounin 537 February 18, 2012 04:46PM

Re: [PATCH] Allow http_auth_request_module to forward 302 responses

Maxim Khitrov 539 February 18, 2012 06:50PM

Re: [PATCH] Allow http_auth_request_module to forward 302 responses

Maxim Dounin 528 February 18, 2012 11:02PM

Re: [PATCH] Allow http_auth_request_module to forward 302 responses

Maxim Khitrov 2169 February 19, 2012 08:42AM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 268
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready