>>> On 4/4/2008 at 5:43 PM, in message <[EMAIL PROTECTED]>, "Paul J. Reder" <[EMAIL PROTECTED]> wrote: > Perhaps it would make more sense to provide this as an explicit value rather > than > On vs. Off and set the default to the previous behavior. Perhaps something > like: > > AuthzMergeRules [AND | OR | OVERRIDE] with default being OVERRIDE (if I grok > correctly) > > Meaning that any directives specified at only one level would be merged to > lower > levels, but the merge behavior of directives specified at multiple levels > would > be controlled by this directive (i.e. ANDed, ORed, or OVERRIDEn with levels > above > it). This could result in complex logic if subsequent levels of containers > mixed > AND, OR, and OVERRIDE, but if it was designed to be explicit then the user > would > have specific control over each authbit along the way. >
When I originally looked at the implementation of the authzMergeRules directive, the above suggestion was my first thought. However I think I decided not to go this route simply because the same thing could be accomplished in a less complex way by making the user explicitly decide the merging rules within the configuration of the directory block itself. In other words, if they wanted OR merging between a higher level and a lower level block, then do nothing or specify <SatisfyOne> in the lower level block. If they wanted AND merging then specify <SatisfyAll> in the lower level block. This follows the same concepts as would be done within a single directory block. This avoids having to resolve logic conflicts and precedents between two different directives, AuthzMergeRules and <SatisfyXXX> Brad