Luke,

I got a chance to look through the new LDAP provider, but I won't be
able to try it out until next week.  Here are some of my thoughts
after looking through the code.

There isn't an easy way to override which UserDetails implementation
is returned.  As it is now, I have to extend
LdapAuthenticationProvider and override createUserDetails.  But since
the authenticator and authoritiesPopulator objects are private, I have
to call super.createUserDetails() to get a User object with the
authorities populated, then create whatever object I wish to return. 
I don't have a good suggestion for overcomming this.  I tried moving
createUserDetails (and authoritiesPopulator) into the
LdapAuthenticator implementation, then just having authenticate()
return a instance of UserDetails, but that didn't feel right either. 
Would applying the strategy pattern to create the user details be
overkill?

Is there a good reason for requiring constructor args instead of
setter methods for properties?  I don't intend to start a flame war
about constructor vs. setter injection, but I do think the setters
should at least be an option, especially to be consistent with the
rest of the acegi configuration.

One minor comment on the DefaultInitialDirContext: there is no way to
enable the useConnectionPool property, that I could see anyway.  I
wish there was LDAP support already in Spring, because the
InitalDirContextFactory really doesn't belong in acegi.  Maybe
we/someone can work on getting it in Spring 2.0.

Overall, I really like the design of the LdapAuthenticationProvider. 
I think using the strategy pattern to split out the authentication and
the authorities was a good call.  The BindAuthenticator and the
DefaultLdapAuthoritiesPopulator should fit 95% of use cases.  The only
potential problem is see is that, like I mentioned, there isn't a good
way to override which UserDetails implementation is returned.

Hope that helps.  Let me know if there is anything I can do to help
move this forward.

Brandon


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to