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.

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
(authenticate/allow/deny/redirect).

- Max

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