>>> On 7/13/2009 at 3:31 PM, in message <[email protected]>, Eric Covener <[email protected]> wrote: > PR#47521 points out that when mod_authnz_ldap has some fatal LDAP > connectivity error, it doesn't allow other AuthBasicProviders to have > a shot at checking the userid. > > It seems like the normal use case for two providers is when there are > two disjoint user repositories, and we only move on to search the > second when the user of interest isn't found in the first. > > For LDAP, should we treat a failure to even search the database this > same way, allowing it to move onto other providers > (AUTH_USER_NOT_FOUND vs. AUTH_GENERAL_ERROR)? It seems to me that the > LDAP backends often have poor reliability and lots of use cases would > want the 2nd provider for emergencies, at little expense (hypothetical > attacker that took out your LDAP servers, and compromised e.g. > AuthUserFile). > > Thoughts?
There are actually two issues to consider in the context of PR#47521. The first issue is what should mod_authn_alias do if it gets an AUTH_GENERAL_ERROR vs AUTH_USER_NOT_FOUND. Apparently, according to the bug, mod_authn_alias just stops which is probably what the intention was when I coded it (years ago in another lifetime ;) . The question here is given this context, should AUTH_GENERAL_ERROR == AUTH_USER_NOT_FOUND? Given this context, the answer is probably yes. However are there any cases dealing with authn_alias where the answer should be no? The second issue is what should authnz_ldap do? Authnz_ldap has already been coded for redundancy if it is configured for it. If there is a problem in this case, then it is a bug that should be looked at. Brad
