RE: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Done - http://opensource2.atlassian.com/projects/spring/browse/SEC-107 Thanks, Scott > -Original Message- > From: Ben Alex [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 19, 2005 6:49 PM > To: acegisecurity-developer@lists.sourceforge.net > Subject: Re: [Acegisecurity-developer] Proposal: Rename > AuthenticationDao interface > > [EMAIL PROTECTED] wrote: > > Thanks guys, > > I'll propose we leave this open for comment one more > day and if there > > aren't any objections I'm willing to make the code and > documentation > > changes this weekend. > > Scott > > > > > Hi Scott > > Please create a JIRA task for the rename. I'll assume we're > going to call it UserDetailsService, and putting it all into > the org.acegisecurity.userdetails package, unless anyone has > any concerns/better ideas? > > 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 > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > --- 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
[EMAIL PROTECTED] wrote: Thanks guys, I'll propose we leave this open for comment one more day and if there aren't any objections I'm willing to make the code and documentation changes this weekend. Scott Hi Scott Please create a JIRA task for the rename. I'll assume we're going to call it UserDetailsService, and putting it all into the org.acegisecurity.userdetails package, unless anyone has any concerns/better ideas? 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Thanks guys, I'll propose we leave this open for comment one more day and if there aren't any objections I'm willing to make the code and documentation changes this weekend. Scott > -Original Message- > From: Tim Kettering [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 10:21 AM > To: acegisecurity-developer@lists.sourceforge.net > Subject: RE: [Acegisecurity-developer] Proposal: Rename > AuthenticationDao interface > > > +1 from me too. I think its better to break stuff now when we still > +have a > excuse (hey, it ain't 1.0 yet) than post 1.0. > > -tim > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Ray Krueger > Sent: Thursday, November 17, 2005 10:01 AM > To: acegisecurity-developer@lists.sourceforge.net > Subject: Re: [Acegisecurity-developer] Proposal: Rename > AuthenticationDao interface > > lol Sorry Scott :) > When Ben puts it like that I gotta agree hehe. > +1 > > On 11/17/05, Dmitriy Kopylenko <[EMAIL PROTECTED]> wrote: > > +1 also > > > > Darrell Kundel wrote: > > +1 > > > > I support the change, it makes more sense to me. > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > On Behalf > > Of Ben Alex > > Sent: Thursday, November 17, 2005 9:23 AM > > To: acegisecurity-developer@lists.sourceforge.net > > Subject: Re: [Acegisecurity-developer] Proposal: Rename > > AuthenticationDao interface > > > > 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
RE: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
+1 from me too. I think its better to break stuff now when we still have a excuse (hey, it ain't 1.0 yet) than post 1.0. -tim -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Krueger Sent: Thursday, November 17, 2005 10:01 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface lol Sorry Scott :) When Ben puts it like that I gotta agree hehe. +1 On 11/17/05, Dmitriy Kopylenko <[EMAIL PROTECTED]> wrote: > +1 also > > Darrell Kundel wrote: > +1 > > I support the change, it makes more sense to me. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf > Of Ben Alex > Sent: Thursday, November 17, 2005 9:23 AM > To: acegisecurity-developer@lists.sourceforge.net > Subject: Re: [Acegisecurity-developer] Proposal: Rename > AuthenticationDao interface > > 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 > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > > > --- > 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_idv28&alloc_id845&op=click > ___ > Home: h
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
lol Sorry Scott :) When Ben puts it like that I gotta agree hehe. +1 On 11/17/05, Dmitriy Kopylenko <[EMAIL PROTECTED]> wrote: > +1 also > > Darrell Kundel wrote: > +1 > > I support the change, it makes more sense to me. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf > Of Ben Alex > Sent: Thursday, November 17, 2005 9:23 AM > To: acegisecurity-developer@lists.sourceforge.net > Subject: Re: [Acegisecurity-developer] Proposal: Rename > AuthenticationDao interface > > 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 > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > > > --- > 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_idv28&alloc_id845&op=click > ___ > Home: http://acegisecurity.org > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > > > --- 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_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
+1 also Darrell Kundel wrote: +1 I support the change, it makes more sense to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Alex Sent: Thursday, November 17, 2005 9:23 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
+1 I support the change, it makes more sense to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Alex Sent: Thursday, November 17, 2005 9:23 AM To: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Quoting Ray Krueger <[EMAIL PROTECTED]>:> 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.OK, thanks, I'll stick with this approach then, but at that rate AuthenticationDao most certainly belongs in the Service layer. No way I'd want to grab the user's info from multiple sources, let alone record their authentication in an audit log without wrapping a transaction around the whole unit of work.I think it again really comes down to whether AuthenticationDao's name is bothersome enough to be worth changing at this time.Scott
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
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. On 11/16/05, Scott McCrory <[EMAIL PROTECTED]> wrote: > > > > Ray Krueger wrote: > >> I do sort of see your point Scott, but I have to agree with Mark here. > >> AuthenticationDao may not be the best name, but it isn't the service. > >> I could see the ProviderManager as a service, or even the > >> AuthenticationProvider, but not the AuthenticationDao. > >> > >> Either way, I think the naming of AuthenticationDao is some what of a > >> semantic issue, and renaming it would have pretty far reaching effect > >> for little gain. My vote, if this is one hehe, would be no as well. > > I'm OK with No if users like me really should be implementing > AuthenticationProvider instead of AuthenticationDao whenever they need to > hit more than one data source. Can someone comment to that? > > Quoting Scott Battaglia <[EMAIL PROTECTED]>: > > Not to suggest any more renaming, but is the "Authentication" part of > > AuthenticationDao even appropriate? :-) In the case of someone using > > CAS, the AuthenticationDao is really being used for Authorization. > > By virtue of using CAS, you are already authenticated. > > Yea, but then again it _is_ acting as a steward for the pre-authenticated > user. I envision this as a buddy getting you a free ticket at a concert. > He is trusted by the band and he already knows (has authenticated) you. The > "authentication" happened before getting to the gates, but he did do it > nonetheless. > > Scott > --- 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_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
> Ray Krueger wrote:>> I do sort of see your point Scott, but I have to agree with Mark here.>> AuthenticationDao may not be the best name, but it isn't the service.>> I could see the ProviderManager as a service, or even the>> AuthenticationProvider, but not the AuthenticationDao. Either way, I think the naming of AuthenticationDao is some what of a>> semantic issue, and renaming it would have pretty far reaching effect>> for little gain. My vote, if this is one hehe, would be no as well.I'm OK with No if users like me really should be implementing AuthenticationProvider instead of AuthenticationDao whenever they need to hit more than one data source. Can someone comment to that?Quoting Scott Battaglia <[EMAIL PROTECTED]>:> Not to suggest any more renaming, but is the "Authentication" part of > AuthenticationDao even appropriate? :-) In the case of someone using > CAS, the AuthenticationDao is really being used for Authorization. > By virtue of using CAS, you are already authenticated.Yea, but then again it _is_ acting as a steward for the pre-authenticated user. I envision this as a buddy getting you a free ticket at a concert. He is trusted by the band and he already knows (has authenticated) you. The "authentication" happened before getting to the gates, but he did do it nonetheless.Scott
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Not to suggest any more renaming, but is the "Authentication" part of AuthenticationDao even appropriate? :-) In the case of someone using CAS, the AuthenticationDao is really being used for Authorization. By virtue of using CAS, you are already authenticated. -Scott Ray Krueger wrote: I do sort of see your point Scott, but I have to agree with Mark here. AuthenticationDao may not be the best name, but it isn't the service. I could see the ProviderManager as a service, or even the AuthenticationProvider, but not the AuthenticationDao. Either way, I think the naming of AuthenticationDao is some what of a semantic issue, and renaming it would have pretty far reaching effect for little gain. My vote, if this is one hehe, would be no as well. -Ray On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: -Original Message- From: Mark St.Godard [mailto:[EMAIL PROTECTED] ... The AuthenticationProvider err.. provides a layer ontop of the actual authenticatonDao, so maybe I am missing something. Hi Mark! Hmmm, it could be me that's been missing it. In my case where I need to hit several DBs, it sounds like I should have instead turned my AuthenticationServiceImpl into AuthenticationProviderImpl (implementing AuthenticationProvider) and get away from Acegi's DaoAuthenticationProvider & AuthenticationDao interfaces altogether. Am I close? To answer your curiosity, our first data source is a reference DB for a user's identity, like whether they're active or terminated, an employee or non-employee, if they're hourly or exempt from overtime, etc. The second DB contains a person's access roles that make sense to couple with the lifecycle of DB #2's records. The third DB contains area management responsibilities and the app's audit log (which we insert into upon every authentication event). A fourth DB will be connected soon that is our fingerprint and background check reference DB. Who knows how many more we may add in the future... :-) Scott --- 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
I do sort of see your point Scott, but I have to agree with Mark here. AuthenticationDao may not be the best name, but it isn't the service. I could see the ProviderManager as a service, or even the AuthenticationProvider, but not the AuthenticationDao. Either way, I think the naming of AuthenticationDao is some what of a semantic issue, and renaming it would have pretty far reaching effect for little gain. My vote, if this is one hehe, would be no as well. -Ray On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Mark St.Godard [mailto:[EMAIL PROTECTED] > > ... > > The AuthenticationProvider err.. provides a layer ontop of > > the actual authenticatonDao, so maybe I am missing something. > > Hi Mark! > > Hmmm, it could be me that's been missing it. In my case where I need to hit > several DBs, it sounds like I should have instead turned my > AuthenticationServiceImpl into AuthenticationProviderImpl (implementing > AuthenticationProvider) and get away from Acegi's DaoAuthenticationProvider > & AuthenticationDao interfaces altogether. Am I close? > > To answer your curiosity, our first data source is a reference DB for a > user's identity, like whether they're active or terminated, an employee or > non-employee, if they're hourly or exempt from overtime, etc. The second DB > contains a person's access roles that make sense to couple with the > lifecycle of DB #2's records. The third DB contains area management > responsibilities and the app's audit log (which we insert into upon every > authentication event). A fourth DB will be connected soon that is our > fingerprint and background check reference DB. Who knows how many more we > may add in the future... :-) > > Scott > > > > --- > 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 > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > --- 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_idv28&alloc_id845&op=click ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
> -Original Message- > From: Mark St.Godard [mailto:[EMAIL PROTECTED] > ... > The AuthenticationProvider err.. provides a layer ontop of > the actual authenticatonDao, so maybe I am missing something. Hi Mark! Hmmm, it could be me that's been missing it. In my case where I need to hit several DBs, it sounds like I should have instead turned my AuthenticationServiceImpl into AuthenticationProviderImpl (implementing AuthenticationProvider) and get away from Acegi's DaoAuthenticationProvider & AuthenticationDao interfaces altogether. Am I close? To answer your curiosity, our first data source is a reference DB for a user's identity, like whether they're active or terminated, an employee or non-employee, if they're hourly or exempt from overtime, etc. The second DB contains a person's access roles that make sense to couple with the lifecycle of DB #2's records. The third DB contains area management responsibilities and the app's audit log (which we insert into upon every authentication event). A fourth DB will be connected soon that is our fingerprint and background check reference DB. Who knows how many more we may add in the future... :-) Scott --- 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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Proposal: Rename AuthenticationDao interface
Hi Scott, From my perspective, I always saw the AuthenticationDao as just that... a pluggable interface for authentication data access (i.e. in-memory, jdbc, ldap, etc.) I personally dont see this interface at a Service Layer level? The AuthenticationProvider err.. provides a layer ontop of the actual authenticatonDao, so maybe I am missing something. I am all for refactoring / renaming, however I would be a little careful since 0.8.3 to 0.9 was a little API change for Acegi users... albeit minor changes. I would think that renaming the AuthenticationDao would be less of a change, compared to the ContextHolder changes. I think the API needs to stabilize... its less shocking for users :) I do kinda see what you mean Scott... having a service layer implement a DAO... normally doesnt sit well with developers ;) Although I am not sure if your situation is common (3 authentication dao's to build up the user's roles?) Just curious why? So if its a vote... mine would be 'no' ** Although I do like that we are all trying to keep the code clean and concise. Good stuff. Cheers, Mark On 11/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi all, I chatted with Ben briefly about this last night and he suggested Ibring it up on the list for others to chime in... I'd like to propose renaming the AuthenticationDao interface toAuthenticationService prior to 1.0.0. Why? It's ultimately just a naming thing, but my feelings are thatAcegi shouldn't delegate authentication to an interface that encourages developers to bypass the business service layer and go straight for the dataaccess layer. And generally, an application's DAOs shouldn't be executingbusiness logic (like role construction) or tapping multiple DB connections, web services and other potential authentication & authorization stores. For example, the app I'm currently working on needs to referencethree different DAOs during authentication to build the user's ultimate list of roles. Clearly this multiple-datasource operation needs to occur withinthe boundaries of a distributed transaction, so I did just that by buildingan AuthenticationServiceImpl that implements AuthenticationDao. This is all well and good, but when I first approached this problem I had to get overthe fact that my *service* needed to implement a *dao* interface. This maynot be so obvious to newcomers already in close combat with Acegi's sophisticated terminology and design. The downside of changing AuthenticationDao to AuthenticationService(sorry, "AuthenticationManager" may be consistent with Spring's nomenclaturebut it's already taken) is that a lot of API code, documentation and example XML files will need to be changed. Users will also have to do the same. Would it be worth it? I don't really know, but the argument couldbe made for making this change now, before 1.0.0 is out, since it's such a core part of Acegi's API. I also believe that it will make the classheirarchy easier to understand and explain, which I think is a challengethat Acegi already faces. I'd be willing to make these changes - Eclipse can easily handle the renaming and dependancy changes, and updating the JavaDoc, reference guide,XML files, etc. is mostly just search-and-replace and validation. But Iwant to know what everyone thinks first. Thanks, Scott---This SF.Net email is sponsored by the JBoss Inc. Get Certified TodayRegister 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.orgAcegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
