RE: [Acegisecurity-developer] Roadmap towards Aceg Security official1.0.0 release
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 isX() 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, almosthttp://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
[Acegisecurity-developer] Re: [Springframework-developer] Roadmap towards Aceg Security official 1.0.0 release
On Dec 29, 2004, at 8:53 PM, Ben Alex wrote: One issue I'd appreciate some comments on is container adapter deprecation. I know some people use the JBoss container adapter (as they need to use EJB security as well), but I've not heard of any usage of the Resin, Tomcat or Jetty adapters. It seems unwise to maintain a suboptimal (non-portable) approach, especially as pre-1.0.0 we can deprecate them. While I found it fairly easy to port a container-managed application to use Acegi, I think it's important to keep the container adapters. Mainly to support Servlet 2.2 applications. Using container-managed authentication usually only requires a handful of lines in web.xml and a few more in a server-specific deployment descriptor. This makes me wonder if there's a simpler way to configure Acegi (consolidating filters?). Or maybe defaults can be set in an XML file in the JAR and then overridden if/when necessary? Ordering of filters seems to be a common problem - it'd be great to somehow make this issue go away by consolidating to one or two filters. Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? +1 Matt --- 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, almosthttp://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
Re: [Acegisecurity-developer] Re: [Springframework-developer] Roadmap towards Aceg Security official 1.0.0 release
On Thu, 30 Dec 2004 15:13:18 -0500, Matt Raible wrote Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? +1 Matt I forgot my +1 on this as well. Scott --- 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, almosthttp://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
Re: [Acegisecurity-developer] Re: [Springframework-developer] Roadmap towards Aceg Security official 1.0.0 release
+1 even though here at Rutgers we are happily using sub-1.x versions in production :-) Scott McCrory wrote: On Thu, 30 Dec 2004 15:13:18 -0500, Matt Raible wrote Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? +1 Matt I forgot my +1 on this as well. Scott --- 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, almosthttp://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
Re: [Acegisecurity-developer] MSc Thesis on middle tier security
Sergio Berna wrote: Andy, I agree that filtering the method response is a fascinating area. The only problem I have always found on filtering a method response is that it doesn't scale properly when performance is an issue. I'm particularly thinking on Collections here, where the full collection check for permissions would degrade performance on big enough collections. Maybe providing intelligent collections and Iterators that perform the security check when accessed could be a wiser approach for that area (like hibernate for lazy load modification). That would imply that a response from a method would be a proxy on the original object that enforces all the security restrictions specified. A generated object wrapper for collections and POJOs that enforces security would be an interesting extension. The necessary hook to add the wrapper is already provided via the AfterInvocationManager. An alternative approach would be to use AspectWerks, rather than something like CGLIB. The nice thing about AspectWerks is a suitable AbstractSecurityInterceptor subclass could also be written that enforces security on domain object instances. In terms of performance, I would never advocate running the existing ACL-based AfterInvocationProviders against large Collections, because not only is there a performance issue at a JVM level to iterate every Collection element, but far more importantly there is the JDBC cost of obtaining the AclEntry[]s from the AclManager. Whilst they do get cached, the AclEntry[]s obviously need to come from the database at some point. This Collection size issue reminds me of someone who was looking for a solution to paginating their Collection results, where the AfterInvocationManager may remove elements. They wanted to ensure the page size was always honoured, even if certain elements were removed due to security. A solution I think was suggested was to retrieve more elements than needed, knowing the AfterInvocationManager would likely remove some of them. I think an alternative was to use a utility class on the client-side, to recall the relevant method repeatedly until the required Collection size is received. A more elegant approach to this problem might be considered in any improvements to the existing AfterInvocationProviders, or any new implementations thereof. 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, almosthttp://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
Re: [Acegisecurity-developer] Re: [Springframework-developer] Roadmap towards Aceg Security official 1.0.0 release
Matt Raible wrote: Using container-managed authentication usually only requires a handful of lines in web.xml and a few more in a server-specific deployment descriptor. This makes me wonder if there's a simpler way to configure Acegi (consolidating filters?). Or maybe defaults can be set in an XML file in the JAR and then overridden if/when necessary? Ordering of filters seems to be a common problem - it'd be great to somehow make this issue go away by consolidating to one or two filters. A single filter that wraps the actual filters is a good idea. I've added it to my TODO list. One good approach to minimising XML configuration complexity in Acegi Security is liked to from http://acegisecurity.sourceforge.net/articles.html. 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, almosthttp://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
