http_auth_request_module Instructions?

[Nginx User]

On Sun, Sep 4, 2011 at 9:00 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Sun, Sep 04, 2011 at 07:40:44PM +0300, Nginx User wrote:
>
> > On Sun, Sep 4, 2011 at 1:25 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > > Hello!
> > >
> > > On Sun, Sep 04, 2011 at 12:02:34AM +0300, Nginx User wrote:
> > >
> > > > Is the any documentation for the http_auth_request_module anywhere?
> > > Trying
> > > > to find out what the configuration parameters are if any.
> > >
> > > Try README in the module tarball.  Alternatively, you may find it
> > > here:
> > >
> >
> >
> > Hi Thanks for that.
> >
> > To clarify, My understanding of how this works is that when a request
> from a
> > client (I'll call this "Client Request") hits Nginx, the module handler
> will
> > spin off a request (I'll call this "Module Request") to a location where
> I
> > would have arranged for authentication to occur. This can be auth basic
> etc
> > or my own custom process. Assuming my own custom process, I should
> arrange
> > for it to return status code "200" to allow access, status code "403" to
> > deny access or status code "401" to ask for username and
> > password (responding by 200, 403 or 401 as required). When the module
> > receives a "200" code for the Module Request, it will pass the Client
> > Request on through to the next normal stage of Nginx processing. If a
> "403"
> > code is received, The user is sent the same and processing stops.
> >
> > Four queries:
> >
> > 1. Is my understanding of the process correct?
>
> Yes.
>
> > 2. When the README says "it is not currently possible to use
> > proxy_cache/proxy_store (and fastcgi_cache/fastcgi_store) for requests
> > initiated by auth request module", does this apply to the Module Request
> > only as it suggests and that the Client Request will proceed as normal or
> is
> > there a twist to it?
>
> It applies only to auth subrequests.  Client requests will proceed
> as usual.
>
> > 3. Does the module cover "post" requests as well
>
> Yes.  Note though, request body won't be read at auth_request (and
> won't be passed to auth subrequest).
>
> > 4. I notice "proxy_set_header X-Original-URI $request_uri;" in the README
> > example. Is this a requirement?
>
> It's just an example how to pass original request uri to your
> custom auth script.
>
> Note though, that
>
>    proxy_pass_request_body off;
>    proxy_set_header Content-Length "";
>
> is actually required when proxy_pass'ing auth subrequests, as
> request body won't read (see above).


Brilliant.

I think a bigger deal should be made of this module as it makes a nonsense
of the "lack of a WAF" concern about Nginx. I'll suggest pushing it to the
core as many are not aware of it. I think the low profile is also because it
is not documented on the wiki. I had clicked on the link in the early days
but on being taken to the sparse website with a few log items, I beat a
hurried retreat.

Since you have Igor's ear, I'll suggest you whisper the following into it:

"Hey Игорь! Я думаю что мы должно сделать этим модуль значения по умолчанию.
Оно закроет вверх все FUD против Nginx о иметь модуль WAF и другой такой
хлам."

On second thoughts, don't ... He might think you have had too much vodka
since that is machine translated.


Last query on this.

The information on the "satisfy" directive in the wiki states that:

* all - Both Access *and* Auth Basic directives must grant access to the
context
* any - Either Access *or* Auth Basic directives grant access to the context
Is this miss leading? Should it be something like:

* all - All access phase handlers must grant access to the context
* any - Any access phase handler can grant access to the context

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20110904/bad62225/attachment.html>