>>> On 4/9/2008 at 11:08 AM, in message <[EMAIL PROTECTED]>, Chris Darroch <[EMAIL PROTECTED]> wrote: > Chris Darroch wrote: > >> Here's another thought: for people doing mass virtual hosting, >> and who let their customers put authn/z directives into .htaccess >> files with "AllowOverride AuthConfig", I would think it may be >> important to ensure that these rules still merge together in the >> way they used to. Otherwise upgrading to 2.4 might mean tracking >> down every .htaccess file and rewriting it to do the right thing >> (sticking in an "AuthzMergeRules Off" or something). For some >> people doing vhosting I suspect that would be a tall order, so it >> would be good if 2.4 would function securely in this situation, >> by default. That said, I don't use .htaccess files and may not >> be making any sense today; my apologies. > > Here's a follow-up notion; admittedly, it represents a lot of > re-refactoring work. It would provide an secure upgrade path for > people with complex configurations, including those with many > legacy .htaccess files to consider. > > A new directive, Accept, is introduced to take the place of > Require. It functions as Require does now in 2.4. Thus we > have two groups of authz directives, old (Require/Satisfy/Order/ > Deny/Allow) and new (Accept/Reject/<SatisfyOne>/<SatisfyAll>). > The old directives function as they did in 2.2. Authz directives > would be parsed and merged as follows: >
I'm not real excited about adding a new authz directive. Authn and authz are already very complex and adding a new directive to the mix will just help to confuse people even more. Especially when they can't tell the difference between 'require' and 'accept' or when they should use one or the other. The requirement to stay somewhat backwards compatible in all of this stuff lends to the confusion already. > 1) Within a per-dir config block (<Location>/<Directory>/etc.) > old and new authz directives may not be mixed. If directives > from both groups appear, a config-time error is thrown. > > 2) When merging new authz directives within a per-dir config > block, the default merge rule is OR, as in 2.4 at present. > This is equivalent to using a <SatisfyOne> around all new authz > directives within a per-dir config block. > > 3) When merging per-dir config blocks at runtime, the following > rules are applied; we'll call the parent block "base" and the > child block "new": > > 3.1) If the new block contains no authz directives, the base's > authz configuration is inherited (if any). This follows > current 2.2 behaviour. > I am OK with this one except for the reason that I mentioned before. By allowing authz to be inherited even when AuthzMergeRules is OFF is kind of a conflict. In other words, since AuthzMergeRules OFF implies an AND, 1 AND 0 should be 0 or no authz rather than inherited authz. However I could buy into this if it seems to make more intuitive sense to the user. > 3.2) If the new block contains old authz directives, the base > block's authz configuration is discarded, and the new block's > authz directives are applied to a clean slate. This follows > current 2.2 behaviour. > > 3.3) If the new block contains new authz directives, the base > and new blocks' authz configurations are merged using > the rule specified by AuthzMergeRules (as it appears within > the new block): > This is where things get a little confusing for me. I'm not really too excited about authz logic behavior changing just because of which version of an authz directive you used. This type of change in behavior isn't intuitive. At least with the way it is now,the behavior change would be between 2.2 and 2.4 rather than two different behaviors in 2.4 itself. > 3.3.1) If AuthzMergeRules is set to Off or is not defined, > the base block's authz configuration is discarded, > and the new block's authz directives are applied to a > clean slate. This follows current 2.2 behaviour, to avoid > confusion and simplify most configurations. > > 3.3.2) If AuthzMergeRules is set to Or or SatisfyOne, the base > block's authz configuration is merged with the new block's > as if they were collectively contained within a <SatisfyOne> > block. > > 3.3.3) If AuthzMergeRules is set to And or SatisfyAll, the base > block's authz configuration is merged with the new block's > as if they were collectively contained within a <SatisfyAll> > block. > This could be OK however I'm not real comfortable with specifying the merging logic in two different ways. In other words, if AuthzMergeRules is set to OR yet <SatisfyAll> is also specified in the same block. The new authz directives may take a little getting used to when first used, but at least there is a consistent way to do things and a behavior that will be consistent in 2.4 without having to worry a lot about "what if"s. > Writing that all out it mostly just seems like a depressingly > large amount of work, but otherwise feels like it might offer a > way forward, both for people upgrading from 2.2 and those starting > fresh with 2.4. Thoughts? > In the end I am all for whatever will make life easier for the person who has to do configuration. The downside to authn and authz is that it has become more complex, the up side is that it has also become more powerful and predictable. I'm just not sure what the right compromise is. Brad
