>>I believe that we are talking about coding at the provider layer
(ldap,
>>file, etc.).
>
>Absolutely not my intention. Again, I do not want to have each
>provider have to reimplement the same code and parsing. I want
>a single module to do so, and the providers to be oblivious
>(but still work.)
Let me clarify, we are talking about coding at the provider framework,
not each provider itself. In other words, the authconfig module would
do basically what you have proposed as far as merging config options
outside of the actual provider module. The only difference would be
allowing the <authconfig> configuration to be aliased so that it can be
reused.
I think we are close to the same page but I will wait to review the
code that you come up with. Also the reason for the syntax <authconfig
ldap alt-ldap> is so that the authconfig module knows what the base
provider is. Otherwise how will it know which provider to call once the
configuration merge is done? Then there would be no need for this
syntax:
<VirtualHost xxx>
<Location /private>
<AuthConfig alt-ldap>
AuthLdap additional or overridden directives
</AuthConfig>
It could be replaced with:
<VirtualHost xxx>
<Location /private>
AuthProvider alt-ldap
AuthLdap additional or overridden directives...
Which more closely maps to the configuration syntax today.
Brad
>>> "William A. Rowe, Jr." <[EMAIL PROTECTED]> Monday, March 07, 2005
4:47:15 PM >>>
At 10:11 AM 3/7/2005, Brad Nicholes wrote:
>I believe that we are talking about coding at the provider layer
(ldap,
>file, etc.).
Absolutely not my intention. Again, I do not want to have each
provider have to reimplement the same code and parsing. I want
a single module to do so, and the providers to be oblivious
(but still work.)
>> [ ] Implement across providers
>> Single <AuthProviderAlias real-provider-name alias> directive.
>
>If they are saying the same thing then we might all be on the same
>page. Now would be a great time to have one of those white board
>discussions like we have at ApacheCon :).
Agreed :)
>I would like to see us implement a syntax that can be reused as
>I suggested earlier. An <AuthProviderAlias ...> tag would allow
>for that. I am -1 to Bill's original proposal mainly because each
>use of an auth module requires that it be reconfigured within it's
><Location> even if the configurations across <Locations> are
identical.
That's not accurate. It's allowed, but remember inheritance applies,
In the module I already hacked, it's possible to
<VirtualHost xxx>
<AuthConfig>
AuthDirectives
</AuthConfig>
and that will also be inherited.
But I didn't propose named aliases, which could be a very cool idea.
>If Bill's original proposal was reworked to pull the <AuthConfig>
>out of the <Location> scope and allow it to be reused as an alias,
>then I am +1.
I'd be even more partial to allowing them in location scope, with
alias names, and merging up the aliases. My concern is names
clashing, on servers with massive VHOST lists. Allowing you to
'refine' a given alias... e.g.
<AuthConfig alt-ldap>
AuthLdapDirectives
</AuthConfig>
<VirtualHost xxx>
<Location /private>
<AuthConfig alt-ldap>
AuthLdap additional or overridden directives
</AuthConfig>
...
then I think your preference for named sections, and my
preference for scoped sections could both be satisfied.
I'll give some thought to binding <AuthConfig > to a specific
provider 'alias', v.s. allowing more complex control.
