[PATCH] Allow http_auth_request_module to forward 302 responses
max at mxcrypt.com
Sat Feb 18 23:48:50 UTC 2012
On Sat, Feb 18, 2012 at 4:45 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 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
The latter may seem odd, given that I'm using cookies, but I also need
the ability to "downgrade" to HTTP Basic authentication for clients
that cannot handle cookies properly. I do this by maintaining a
whitelist of clients that are known not to support cookies (e.g.
mercurial or various scripted clients). When my authentication
back-end sees a matching User Agent string, it automatically allows
the use of Basic authentication by sending a 401 response. Everyone
else will be either denied access or be redirected to provide their
credentials via an html form.
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
More information about the nginx-devel