So it sounds like there are two questions being asked. First, what non-ldap
usages are there for authnAlias and second why doesn't the configuration below
work?
I'll answer the second question first. Given the configuration block below,
I don't know why it doesn't work. I just retested the same configuration and
everything worked as expected. The only issue that I see is setting
'AuthBasicAuthoritative off'. Since there doesn't appear to be any other
authentication type specified (ie. digest), this directive should either be set
to 'on' or removed and left as default (which is also 'on'). The error message
that is showing up in the error_log is a result of the default authn handler
being hit as a last resort with no auth type set as default. BTW, given the
configuration below, I was also unable to duplicate the error message even with
AuthBasicAuthoritative set to 'on' which implies that there is probably some
other auth configuration somewhere that is conflicting.
To answer the first question, the non-ldap example given here is a perfectly
valid use of authnAlias. Basically authnAlias can be used to create extended
providers that use the same base provider but with different parameters.
Another possible example would be authnDBD:
<AuthnProviderAlias dbd dbd1>
AuthDBDUserPWQuery "select password from authn where username = %s"
</AuthnProviderAlias>
<AuthnProviderAlias dbd dbd2>
AuthDBDUserPWQuery "select password from authn where Aliasusername = %s"
</AuthnProviderAlias>
Of course you could craft a better SQL statement that would handle both
situations at the same time, but you get the point. AuthAlias just appears to
be more useful with LDAP because configuring authnzldap authentication usually
requires more than a single directive that defines authentication criteria (ie.
ldap server, bind user and password).
Brad
>>> On 9/5/2006 at 6:54 AM, in message
<[EMAIL PROTECTED]>, Rich Bowen
<[EMAIL PROTECTED]> wrote:
> This went first to users@, but it appears that the auth-fu isn't
> strong there right now. ;-)
>
> I was hoping that someone (Brad?) might be able to assist me with
> this. I was trying to come up with a non-LDAP example for the
> documentation, since this seems a really useful feature that should
> be accessible to folks that don't use LDAP. But so far no joy.
>
> Begin forwarded message:
>
>> From: Rich Bowen <[EMAIL PROTECTED]>
>> Date: September 4, 2006 16:34:45 EDT
>> To: [email protected]
>> Subject: [EMAIL PROTECTED] AuthProviderAlias and mod_authn_file
>> Reply-To: [email protected]
>>
>> I'm trying to come up with a working example of using
>> AuthProviderAlias with something other than LDAP. I'm sure I'm
>> overlooking something simple, but I can't get it working, and could
>> use some advice. Here's what I've got:
>>
>> <AuthnProviderAlias file file1>
>> AuthUserFile /tmp/auth1
>> </AuthnProviderAlias>
>>
>> <AuthnProviderAlias file file2>
>> AuthUserFile /tmp/auth2
>> </AuthnProviderAlias>
>>
>> <Directory /usr/local/apache/vhosts/drbacchus/x>
>> AuthType Basic
>> AuthName 'wooga'
>> AuthBasicAuthoritative off
>> AuthBasicProvider file1 file2
>>
>> Require valid-user
>> </Directory>
>>
>> On trying to authenticate, I get the following in the error log:
>>
>> access to /x failed, reason: require directives present and no
>> Authoritative handler.
>>
>> Any advice would be greatly appreciated. With any luck, I'll figure
>> it out as soon as I press send ...
>
> --
> They went to sea in a sieve, they did
> In a sieve they went to se
