<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Sep 4, 2011 at 9:00 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello!<br>
<div class="im"><br>
On Sun, Sep 04, 2011 at 07:40:44PM +0300, Nginx User wrote:<br>
<br>
> On Sun, Sep 4, 2011 at 1:25 AM, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br>
><br>
> > Hello!<br>
> ><br>
> > On Sun, Sep 04, 2011 at 12:02:34AM +0300, Nginx User wrote:<br>
> ><br>
> > > Is the any documentation for the http_auth_request_module anywhere?<br>
> > Trying<br>
> > > to find out what the configuration parameters are if any.<br>
> ><br>
> > Try README in the module tarball. šAlternatively, you may find it<br>
> > here:<br>
> ><br>
><br>
><br>
> Hi Thanks for that.<br>
><br>
> To clarify, My understanding of how this works is that when a request from a<br>
> client (I'll call this "Client Request") hits Nginx, the module handler will<br>
> spin off a request (I'll call this "Module Request") to a location where I<br>
> would have arranged for authentication to occur. This can be auth basic etc<br>
> or my own custom process. Assuming my own custom process, I should arrange<br>
> for it to return status code "200" to allow access, status code "403" to<br>
> deny access or status code "401" to ask for username and<br>
> password (responding by 200, 403 or 401 as required). When the module<br>
> receives a "200" code for the Module Request, it will pass the Client<br>
> Request on through to the next normal stage of Nginx processing. If a "403"<br>
> code is received, The user is sent the same and processing stops.<br>
><br>
> Four queries:<br>
><br>
> 1. Is my understanding of the process correct?<br>
<br>
</div>Yes.<br>
<div class="im"><br>
> 2. When the README says "it is not currently possible to use<br>
> proxy_cache/proxy_store (and fastcgi_cache/fastcgi_store) for requests<br>
> initiated by auth request module", does this apply to the Module Request<br>
> only as it suggests and that the Client Request will proceed as normal or is<br>
> there a twist to it?<br>
<br>
</div>It applies only to auth subrequests. šClient requests will proceed<br>
as usual.<br>
<div class="im"><br>
> 3. Does the module cover "post" requests as well<br>
<br>
</div>Yes. šNote though, request body won't be read at auth_request (and<br>
won't be passed to auth subrequest).<br>
<div class="im"><br>
> 4. I notice "proxy_set_header X-Original-URI $request_uri;" in the README<br>
> example. Is this a requirement?<br>
<br>
</div>It's just an example how to pass original request uri to your<br>
custom auth script.<br>
<br>
Note though, that<br>
<br>
 š šproxy_pass_request_body off;<br>
 š šproxy_set_header Content-Length "";<br>
<br>
is actually required when proxy_pass'ing auth subrequests, as<br>
request body won't read (see above).</blockquote><div><br></div><div>Brilliant.š</div><div><br></div><div>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.</div>
<div><br></div><div>Since you have Igor's ear, I'll suggest you whisper the following into it:</div><div><br></div><div>"Hey éÇÏÒØ! ñ ÄÕÍÁÀ ÞÔÏ ÍÙ ÄÏÌÖÎÏ ÓÄÅÌÁÔØ ÜÔÉÍ ÍÏÄÕÌØ ÚÎÁÞÅÎÉÑ ÐÏ ÕÍÏÌÞÁÎÉÀ. ïÎÏ ÚÁËÒÏÅÔ ××ÅÒÈ ×ÓÅ FUD ÐÒÏÔÉ× Nginx Ï ÉÍÅÔØ ÍÏÄÕÌØ WAF É ÄÒÕÇÏÊ ÔÁËÏÊ ÈÌÁÍ."</div>
<div><br></div><div>On second thoughts, don't ... He might think you have had too much vodka since that is machine translated.</div><div><br></div><div>š</div><div>Last query on this.</div><div><br></div><div><div>The information on the "satisfy" directive in the wiki states that:</div>
<div><br></div><div>* all - Both Access *and* Auth Basic directives must grant access to the context</div><div>* any - Either Access *or* Auth Basic directives grant access to the context</div><div>Is this miss leading? Should it be something like:</div>
<div><br></div><div>* all - All access phase handlers must grant access to the context</div><div>* any - Any access phase handler can grant access to the context</div><div><br></div><div>Thanks</div></div></div></div>