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.
