"Robert r. Sanders" <[EMAIL PROTECTED]> writes:
> Ben,
> Sorry about not being more active lately; I've been trying to
> finish up a project at work and its been sucking up all my time.
> Anyway, I never got anything from Joseph (unless it got caught in
> my spam filters). Within 2-3 weeks or so I hope to get the new
no, it didn't get caught anywhere.
> version of the LDAP DAO stuff 'finished' off w/ some unit tests.
> Currently what's in CVS is the latest I've got, I haven't even had
> time to even run any reality checks against my internal LDAP
I can go ahead and send you the changes I made. but before I do that,
I'd like to ask for some advice.
what's needed here is something which will do authentication against
LDAP first, but will also delegate to some other provider in case the
LDAP authentication fails. my first attempt at this was to use two
totally distinct providers, but it seems that Acegi will only use the
first provider that claims to support a given Authentication. so that
was out.
since that didn't work, I decided to change loadByUsernameAndPassword
to something like this:
public UserDetails loadUserByUsernameAndPassword(String username, String pas
sword) throws DataAccessException, BadCredentialsException {
if ((password == null) || (password.length() == 0)) {
throw new BadCredentialsException("Empty password");
}
UserDetails user = null;
try {
user = doLdapAuthentication(username, password);
}
catch (Exception e) {
e.printStackTrace();
}
if (user == null) {
user = doLocalAuthentication(username, password);
}
return user;
}
protected UserDetails doLdapAuthentication(String username, String password)
{
// actual LDAP authentication ...
...
}
protected UserDetails doLocalAuthentication(String username, String password
) {
return null;
}
the idea being that subclasses could override doLocalAuthentication to
do whatever they need to do in that case.
this works, but it means that your LDAP authentcation bean has to also
know about the "local" authentication details, password encoder, salt
source, etc., which seems less than ideal.
anyhow, if anyone has any suggestions about this (which really has
nothing to do with LDAP) then I can try incorporating them into my
changes before sending them back to you. if I don't hear anything by
tomorrow, I'll go ahead and send you what I've got.
>> Robert r. Sanders wrote:
>>
>>> If you won't mind sending me you changes, I'll try to get them
>>> merged with the LDAP DAO stuff.
>>
>> Hi Robert and Joseph
>>
>> How did you end up going with the LDAP changes? What is the present
>> status of LDAP and the Apache DS unit tests? LDAP is an important
>> feature for a 1.0.0 release.
>>
>> Thanks
>> Ben
>>
>
> --
> Robert r. Sanders
> Chief Technologist
> iPOV
> (334) 821-5412
> www.ipov.net
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>>From IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Home: http://acegisecurity.sourceforge.net
> Acegisecurity-developer mailing list
> Acegisecurity-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
>
>
--
joe
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
