+1 in concept as well but it seems that this should be implemented at some lower level so that we don't have to touch each authz module to teach them how to deal with the satisfy directive.
The problem is that the auth_checker hook is defined as AP_IMPLEMENT_HOOK_RUN_FIRST meaning that each registered hook will be called in turn until something other than DECLINE is returned. If something other than DECLINE is returned then the appropriate action takes place. Either authorization succeeds or fails with a specific error. Satisfy All would need to change the behavior of the hook so that each registered hook is called in turn as long as OK or DECLINE is returned. Then if something other than OK or DECLINE is returned, the authorization fails. This would probably require defining a new type of hook that would be defined as AP_IMPLEMENT_HOOK_RUN_ALL. At this point I am not sure how to make that happen without drastically altering the way authorization is currently configured and works. Currently Satisfy All | Any is very specific in how it is implemented inside of ap_process_request_internal(). It's purpose is to satisfy access control vs. (authentication and authorization). This would also need to be changed or use something other than the Satisfy directive. Brad >>> On Monday, September 05, 2005 at 4:15:56 am, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Ryan Morgan wrote: > >> require ldap-group cn=Engineering,ou=Groups,o=SomeCompany,c=US >> require ldap-group cn=QA,ou=Groups,o=SomeCompany,c=US >> satisfy all > >> Could someone provide feedback on whether this is a feature that could be >> added to the ldap module? > > Definitely a +1 in concept. Do the other authz modules handle satisfy > all in the same way? > > A quick eyeball of the patch shows up some C++ comments - can you > convert them to C comments? > > Regards, > Graham > --
