|Nginx User||Sep 3, 2011 2:01 pm|
|Maxim Dounin||Sep 3, 2011 3:24 pm|
|Nginx User||Sep 4, 2011 9:40 am|
|Maxim Dounin||Sep 4, 2011 11:00 am|
|Nginx User||Sep 4, 2011 12:07 pm|
|Andrey N. Oktyabrski||Sep 4, 2011 12:32 pm|
|Nginx User||Sep 4, 2011 12:49 pm|
|Maxim Dounin||Sep 4, 2011 3:00 pm|
|Nginx User||Sep 4, 2011 3:35 pm|
|Subject:||Re: http_auth_request_module Instructions?|
|From:||Maxim Dounin (mdou...@mdounin.ru)|
|Date:||Sep 4, 2011 11:00:00 am|
On Sun, Sep 04, 2011 at 07:40:44PM +0300, Nginx User wrote:
On Sun, Sep 4, 2011 at 1:25 AM, Maxim Dounin <mdou...@mdounin.ru> wrote:
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.
1. Is my understanding of the process correct?
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).