Ben, I agree that these 2 methods could be directly inserted in the UserDetails interface but its your decision that counts there (as the father of the child ;) ).
In fact I introduced them there first, but while modifying DaoAuthenticationProvider I realized that if people simply changed the acegi jar on their respective installations they would get a NoSuchMethodException and would be forced to modify their code implementing the 2 new methods. That's why I introduced the interface, so that I could check wheter UserDetails was extended with expiration information before calling the methods. Anyway, I'll perform all the modifications requested for the methods and UserDetails inclusion and will also modify the existing UserDetails implementations (User) as you suggest. I will also modify existing test cases for UserDetails so that it includes both expiration checks and the corresponding doc. Happy new year! Sergio. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Ben Alex Enviado el: viernes, 31 de diciembre de 2004 0:18 Para: acegisecurity-developer@lists.sourceforge.net Asunto: Re: [Acegisecurity-developer] Roadmap towards Aceg Security official1.0.0 release Sergio Berna wrote: > >I have added ExpirationDetails as a separate interface to keep backwards >compatibility with existing code that implementes UserDetails. > > > > Hi Sergio Good to see backward compatibility is a priority, particular in such a sensitive (ie commonly-deployed and extended) area as DaoAuthenticationProvider and UserDetails. I am just wondering whether it would be simpler, though, to modify the UserDetails interface so it contains the isAccountExpired() and isCredentialsExpired() methods? Then the existing constructor of the User implementation - which is what most people use - could set the properties to false. There would also be an additional constructor which AuthenticationDaos could use if they had access to the additional properties. We should probably also deprecate the existing constructor, to prompt people to consider the change (and move the decision to set the properties to a false default into their AuthenticationDao construction of User). For the small minority of people who have chosen NOT to extend User (which goes against our recommendations, but there are legitimate scenarios such as having a domain object that already represents the user), I don't think adding two methods to their implementation is going to cause much concern - especially as they can simply return false. This alternative would still provide 95% of users with full backwards compatibility, but avoid an extra interface. As the project also provides basic implementations of each interface, it also avoids us needing to write a UserExpirationDetails (for example). It is also cleaner to avoid these extra classes given that people often cast the contents of ((SecureContext)ContextHolder.getContext()).getAuthentication().getPrincip al(). It also makes these new properties and exceptions non-optional concepts in the overall framework, which means we will modify the included AuthenticationDaos (eg in-memory and JDBC), as well as the exception resolvers, to accommodate them. One other thing is the method names. I think it would be better to keep "true" being consistently returned as the affirmative/positive indication from each isXxxxx() method on UserDetails (there is already UserDetails.isEnabled()). So perhaps rename the methods to isCredentialsNonExpired() and isAccountNonExpired(), or something similar. Best regards Ben ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 265.6.7 - Release Date: 30/12/2004
smime.p7s
Description: S/MIME cryptographic signature
