9 messages in ru.sysoev.nginxRe: http_auth_request_module Instruct...| From | Sent On | Attachments |
|---|---|---|
| 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: | Nginx User (ngi...@nginxuser.net) | |
| Date: | Sep 4, 2011 12:07:47 pm | |
| List: | ru.sysoev.nginx | |
On Sun, Sep 4, 2011 at 9:00 PM, Maxim Dounin <mdou...@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 <mdou...@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
_______________________________________________ nginx mailing list ngi...@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx