Http_auth_request_module Instructions?

Server NGINX
1

Is the any documentation for the http_auth_request_module anywhere?
Trying
to find out what the configuration parameters are if any.

Thanks

2

Hello!

On Sun, Sep 04, 2011 at 12:02:34AM +0300, Nginx U. 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:

http://mdounin.ru/hg/ngx_http_auth_request_module/file/tip/README

Maxim D.

3

On Sun, Sep 4, 2011 at 1:25 AM, Maxim D. [email protected] wrote:

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?
  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?
  3. Does the module cover “post” requests as well
  4. I notice “proxy_set_header X-Original-URI $request_uri;” in the
    README
    example. Is this a requirement?

Thanks again

4

Hello!

On Sun, Sep 04, 2011 at 07:40:44PM +0300, Nginx U. wrote:

Try README in the module tarball. Alternatively, you may find it
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.

  1. 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.

  1. 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).

  1. 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).

Maxim D.

5

On 04.09.11 23:08, Nginx U. wrote:

“Hey !
. FUD Nginx WAF
.”
Excuse me, your english much better than russian, please use it :slight_smile:

6

On Sun, Sep 4, 2011 at 9:00 PM, Maxim D. [email protected] wrote:

Is the any documentation for the http_auth_request_module anywhere?
To clarify, My understanding of how this works is that when a request
deny access or status code “401” to ask for username and
Yes.

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

7

2011/9/4 Andrey N. Oktyabrski [email protected]

On 04.09.11 23:08, Nginx U. wrote:

“Hey !
. FUD Nginx WAF
.”

Excuse me, your english much better than russian, please use it :slight_smile:

You obviously type faster than you read since you managed to send your
email
before you finished reading the next line which says …

On second thoughts, don’t … He might think you have had too much vodka

since that is machine translated.

You should learn to read a bit faster but we digress :slight_smile:

8

Hello!

On Sun, Sep 04, 2011 at 10:08:30PM +0300, Nginx U. wrote:

[…]

  • any - Any access phase handler can grant access to the context
    Both versions are right, though first one implicitly assumes you
    are using only standard access modules.

Maxim D.

9

On Mon, Sep 5, 2011 at 1:01 AM, Maxim D. [email protected] wrote:

  • 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

Both versions are right, though first one implicitly assumes you
are using only standard access modules.

I’ll say the first set is technically wrong as it implies the
directive
only applies to those two modules. The key is in the use of the words
“both”
and “either” which imply a sum total of two possibilities.

I edited the wiki to read:

Access policy if directives from multiple access phase handlers, such as
the
Access and Auth Basic modules, are defined in a context:

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

Thanks!