>>> On 2/18/2006 at 4:59 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > Ruediger Pluem wrote: >> >> On 02/18/2006 11:46 PM, David Reid wrote: >>> Ruediger Pluem wrote: >>>> So please revert or fix. >>> >>> Why are people so quick to ask for reversion these days? >> >> Please note that I said revert *or* fix. >> I fully understand (not in technical detail) the trouble you have with the > reworked >> parts of the auth system. Although I know that this is not required, I like > to see >> the trunk at least compilable without further patches to continue other work > on it. >> I also appreciate your work on cleaning out the bugs and problems on the > reworked >> auth code, but if this takes commits that make the code somewhat > uncompilable please >> open a branch and merge it once your work is finished. I think this would > satisfy >> everybody's needs. > > Nothing personal, just that people seem mmore willing to shout "revert" > than to look and fix it. You did do that - so apologies if it sounded > like I was having a go. :-) > > My biggest complaint is the lack of documentation or attempt at > documentation of the revised config. I'm more than willing to try the > new code and new config options, but if I can't find anything that tells > me how to make the change it's hard. Auth config has never been the > easiest thing in the first place. It seems that every time about how to > make the changes I ask I'm just told to "use the compat module". Are > people trying to move things along or not? >
Well I tried, (http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=113659184312078&w=2) , as well as trying to get all of the documentation for the directives and how-to up to date. In fact all of this work was completed on the authz-dev branch before being merged into trunk. If you read through this message thread you will see that there were a number of things that changed that should ultimately make auth easier to configure. The problem that we have now is transition. There is the old way of doing auth and there is the new way of doing auth. If you want to use the old way or you want to mix them, then you have to use mod_access_compat. There were also a few APIs that became obsolete or reclassified as optional . ap_requires() - Removed. Reason: No longer needed in the provider based model since all 'Require' args are stored per-provider and not as a single array. ap_auth_type(), ap_auth_name(), ap_some_auth_required() - Reclassified optional. Reason: The implementation of these functions was moved to the authn or authz core modules where it belongs rather than in httpd core. The APIs that continue to exist in httpd core attempt to call the optional functions if available or return NULL of not. ap_satisfies() - Obsolete. Reason: The 'Satisfy' directive has been deprecated and the implementation has been moved to mod_access_compat. It is expected to be removed completely in Apache 3.0. Since ap_satisfies() is obsolete, I did not provide a stub function in core as was done with ap_auth_type(), ap_auth_name() and ap_some_auth_required(). The reasoning behind this decision was because ap_satisfies() has an expected end of life while the other APIs do not. Therefore all modules going forward should be reworked to eliminate the need for ap_satisfies(). However, to support backwards compatibility until mod_access_compat is removed in Apache 3.0, the optional function has been provided. Out of convenience I could implement a stub function in core which would attempt to call the ap_satisfies() optional function if mod_access_compat has been loaded. But this seems much more dangerous than forcing the module to import the function and making sure that it can handle the NULL return if mod_access_compat has not been loaded. Brad
