On Thu, Aug 4, 2011 at 3:02 PM, Eric Covener <[email protected]> wrote:
>> <LimitExcept GET>
>> #Require group hgpushers
>> Require group poopy
>> </LimitExcept>
>> </Location>
>
> Do you need to wrap the "require valid-user" in a LimitExcept so it's
> not in effect for your more restricted methods?
Well, yes; that seems to force the behavior I'm looking for:
<Limit GET>
Require valid-user
</Limit>
<LimitExcept GET>
# Relies on AuthGroupFile set above for this vhost
#Require group hgpushers
Require group poopy
</LimitExcept>
[Thu Aug 04 17:34:01 2011] [info] [client 10.8.209.142] Connection to
child 6 established (server xxx:443)
[Thu Aug 04 17:34:01 2011] [info] Seeding PRNG with 144 bytes of entropy
[Thu Aug 04 17:34:01 2011] [info] Initial (No.1) HTTPS request
received for child 6 (server xxx:443)
[Thu Aug 04 17:34:01 2011] [error] [client 10.8.209.142] Authorization
of user drspruel to access /hg/main failed, reason: user doesn't
appear in group file (/etc/httpd/auth/groups).
[Thu Aug 04 17:34:01 2011] [info] [client 10.8.209.142] Connection
closed to child 6 with standard shutdown (server xxx:443)
So I take it that the original configuration had a satisfied Require
as valid-user that evaluated properly and must have therefore bypassed
evaluating further the more restrictive requirement introduced in the
LimitExcept; I wouldn't expect this to be the desired behavior though,
if that's the case.
This new configuration seems a bit overexplicit and kludgey, is there
anything I'm missing? Perhaps a directive similar to 'Satisfy' for
authorization decisions that causes a more specific clause to
override?
Or is this the preferred/recommended way to approach this case?
--
Darren Spruell
[email protected]
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: [email protected]
" from the digest: [email protected]
For additional commands, e-mail: [email protected]
