On 1/6/06, Brad Nicholes <[EMAIL PROTECTED]> wrote: > The Authz refactoring in /branch/authz-dev is basically done and I am > about ready to merge the branch back into trunk. Before I do that, I > would like to describe the impact that the Authz change will have going > forward, as well as the benefits. All of this looks like a massive > change to authorization and access control, which granted it is. > However, I have tried as much as possible to minimize the impact to > existing configuration files.
These are my comments based on a very superficial look. First, I think the overall idea is great and much clearer than what we have now. But I do think the necessary config changes are rather massive, touching a large percentage of .htaccess files and <Directory> sections, not to mention third-party auth modules. I would think that, by sacrificing some purity, it should be possible to support many of these configs and modules. For example, shouldn't it be possible to create a mod_access_deprecated that impliments Order/Allow/Deny? Obviously satisfy would add a lot of complication, but I bet 90%+ of existing configs would work fine if the default Satisfy All was made to work, so the Satisfy directive itself probably wouldn't need to be included. I guess an alternative would be a fancy python script to convert config/.htaccess files. As far as the new config directives, a couple questions: 1. Why split "Allow from" into "Require ip" and "Require host". There is no ambiguity between a hostname and an IP address, as far as I know, so it would seem more straightforward to have only "Require host" and let httpd figure out whether it is an IP address or hostname. 2. "Require all granted" and "Require all denied" seem a little obtuse to me. As evidence, I note that you chose to document them by refering to the old config, rather than explaining what they do ;-) Perhaps simply "Require host *" and "Reject host *" or "Require host all"/"Reject host all" would be clearer alternatives. (In the process, getting rid of another Require option and getting us closer to a more familiar config.) 3. The <RequireAll> and <RequireOne> names seem a touch confusing given that they apply to both require and reject directives. Perhaps back to the good old <SatisfyAll/One> or <MatchAll/One>? 4. It isn't made clear anywhere whether RequireAll or RequireOne is the default. Joshua.
