httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: svn commit: r378394 - /httpd/httpd/trunk/modules/aaa/mod_auth.h
Date Mon, 20 Feb 2006 23:07:39 GMT
>>> On 2/18/2006 at 4:59 pm, in message
<>, 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
> 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
> satisfy
>> everybody's needs.
> Nothing personal, just that people seem mmore willing to shout
> than to look and fix it. You did do that - so apologies if it
> 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
> new code and new config options, but if I can't find anything that
> 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
> 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,
, 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.


View raw message