Ray Krueger wrote:
You currently have an AuthenticationDao that successfully returns a
UserDetails instance that is built up by your four database scheme
now, correct? The whole point of the AuthenticationDao is to build a
UserDetails instance, by whatever means necessary. So, no, users like
you should do exactly what you're doing. I don't see a reason for you
two implement a new AuthenticationProvider, unless the
DaoAuthenticationProvider is not meeting you're needs.
The one and only method defined by AuthenticationDao is:
public UserDetails loadUserByUsername(String username) throws
UsernameNotFoundException, DataAccessException;
AuthenticationDao is used variously within the system:
Implementation: JdbcDaoImpl
Implementation: InMemoryDaoImpl
User: DaoAuthenticationProvider
User: DaoCasAuthoritiesPopulator
User: DaoX509AuthoritiesPopulator
User: DigestProcessingFilter
User: TokenBasedRememberMeServices
User: SwitchUserProcessingFilter
AuthenticationDao is presently found in the
org.acegisecurity.providers.dao package. Given only the first three
classes above are actually in that package or a subpackage, perhaps
AuthenticationDao should be moved to a higher-level package to reflect
its broader use in five other areas of the framework. We faced a similar
transition for UserDetails itself, from the DAO package to the top-level
package for a similar reason.
Whilst it's mostly semantics, the other side is clarifying relationships
and scope of services within the framework. Perhaps we should rename
org.acegisecurity.providers.dao.AuthenticationDao to
org.acegisecurity.UserDetailsService. It will mean that most users have
to make a fairly minor change
to the interface they're implementing in their AuthenticationDao
implementations, but aside from that it will be transparent. If we do
this, it might even be better to make an org.acegisecurity.userdetails
package, to hold UserDetails, User, UserDetailsService and the two
implementations listed above. At least we'd be emphasising "these
classes can be used anywhere within the framework or by your code" - not
just for DaoAuthenticationProvider.
Anyhow, I note the current responses consider this mostly a semantics
issue, but I tend to see where Scott's coming from regarding clarifying
architectural use and layering. We can make these moves with losing
revision history (I feel game - I'll log another SF CVS job! :-) ). And
users are already going to be *having* to change the import of their
AuthenticationDao implementations anyway, due to the package rename in
SEC-104.
Thoughts?
Cheers
Ben
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
