httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject What does the Authz "reject" directive really mean...
Date Fri, 28 Jul 2006 22:30:51 GMT
   There is a new concept (directive) that has been added to the authorization (access control)
portion of the web server.  This new concept is "reject".  Basically what this directive does
is allow you to specify conditions by which access or authorization is denied.  The question
I have is how binding should "reject" be when found within a hierarchy set of authorization
rules?   Given the following configuration for example:

Alias /pages /www/pages

<Directory /www/pages>
   Reject ip

<Directory /www/pages/secure>
   Authtype Basic
   AuthName Something
   AuthBasicProvider file
   AuthUserFile /somewhere/usr.dat
      Require valid-user
      Reject user joe

In this case is the user granted or denied access to the following URL: 
user: betty

betty would be a valid user and the user name != joe but the ip is  In other words
if the authorization directives specified in both <Directory> blocks are OR'ed together
then authorization would be GRANTED since the result of the second block is GRANTED.  However
if the blocks are AND'ed together or the "reject" directive is definitive, then the result
would be DENIED.  Under the current implementation the implied merge would be an OR operation
resulting in access GRANTED.  So I guess my question is, should "reject" be definitive?  If
a "reject" rule is ever encountered  and satisfied within the logic of authorization, is access
automatically denied no matter what any of the other rules might produce?  I am leaning towards
'yes, access should be denied'.  



View raw message