[Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext
Pursuant to Juergen's recommendation (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), Acegi Security CVS has now had its ContextHolder and related classes removed. This functionality has been replaced by SecurityContext, which is an InheritableThreadLocal that provides a single getter/setter pair for Authentication. This is a significant change for end users, but offers a number of benefits: - Consistency with Spring core's use of a concrete ThreadLocal per functional area - SecurityContext is strictly typed (which eliminates the need for casting) - Simplified configuration as no need to specify a Context implementation for HttpSessionContextIntegrationFilter - InheritableThreadLocal used instead of ThreadLocal to simplify rich client usage (see http://forum.springframework.org/viewtopic.php?t=5004) - Elimination of handling the extra Context layer means less end user code is required Unit tests pass and I've updated the upgrade-080-090.txt in some detail. The reference guide has also been updated. It would be appreciated if developers could try the latest CVS with their applications and report any difficulties. General feedback on this change is also welcome. Cheers Ben --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ 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] Acegi Security's ContextHolder replaced by SecurityContext
Ben Alex wrote: Pursuant to Juergen's recommendation (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), Acegi Security CVS has now had its ContextHolder and related classes removed. This functionality has been replaced by SecurityContext, which is an InheritableThreadLocal that provides a single getter/setter pair for Authentication. This is a significant change for end users, but offers a number of benefits: - Consistency with Spring core's use of a concrete ThreadLocal per functional area - SecurityContext is strictly typed (which eliminates the need for casting) - Simplified configuration as no need to specify a Context implementation for HttpSessionContextIntegrationFilter - InheritableThreadLocal used instead of ThreadLocal to simplify rich client usage (see http://forum.springframework.org/viewtopic.php?t=5004) - Elimination of handling the extra Context layer means less end user code is required Unit tests pass and I've updated the upgrade-080-090.txt in some detail. The reference guide has also been updated. It would be appreciated if developers could try the latest CVS with their applications and report any difficulties. General feedback on this change is also welcome. As I read Juergen's suggestion, I thought he was just suggesting to go away from the ContextHolder with abitlity to hold a generic Context, as it is potentially confusing as to what is going to go in there. So he suggested a SecurityContextHolder which needs to hold a SecurityContext. However, it seems to me that this simplification is much more than that, and may have gone too far, as it's all been collapsed into the one SecurityContext which is the threadlocal (effectively) and holds the Authentication. Unless I'm missing something it would still be of real use to have a real SecurityContextHolder which holds a pluggable SecurityContext. Then people can subclass that if needed to add extra data. The difference from before however is that now it is clearly security focused, and the lifecycle of the object is managed clearly by Acegi. What does everybody think? -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - From the Source http://www.springframework.com --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Springframework-developer] Re: [Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext
Colin Sampaleanu wrote: Ben Alex wrote: Pursuant to Juergen's recommendation (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), Acegi Security CVS has now had its ContextHolder and related classes removed. This functionality has been replaced by SecurityContext, which is an InheritableThreadLocal that provides a single getter/setter pair for Authentication. This is a significant change for end users, but offers a number of benefits: - Consistency with Spring core's use of a concrete ThreadLocal per functional area - SecurityContext is strictly typed (which eliminates the need for casting) - Simplified configuration as no need to specify a Context implementation for HttpSessionContextIntegrationFilter - InheritableThreadLocal used instead of ThreadLocal to simplify rich client usage (see http://forum.springframework.org/viewtopic.php?t=5004) - Elimination of handling the extra Context layer means less end user code is required Unit tests pass and I've updated the upgrade-080-090.txt in some detail. The reference guide has also been updated. It would be appreciated if developers could try the latest CVS with their applications and report any difficulties. General feedback on this change is also welcome. As I read Juergen's suggestion, I thought he was just suggesting to go away from the ContextHolder with abitlity to hold a generic Context, as it is potentially confusing as to what is going to go in there. So he suggested a SecurityContextHolder which needs to hold a SecurityContext. However, it seems to me that this simplification is much more than that, and may have gone too far, as it's all been collapsed into the one SecurityContext which is the threadlocal (effectively) and holds the Authentication. Unless I'm missing something it would still be of real use to have a real SecurityContextHolder which holds a pluggable SecurityContext. Then people can subclass that if needed to add extra data. The difference from before however is that now it is clearly security focused, and the lifecycle of the object is managed clearly by Acegi. What does everybody think? As a follow-up, from memory (it's been about a year) I believe I used a custom SecureContext to also pass along some EJB related security information (principal name, or the ejb run-as user) between different layers along with the Acegi specific info. The app in question was a mixed EJB and Spring app, using the EJB version of OSWorkflow. In general, I think if by default the user does not have to specify the actual SecurityContext implementation class unless they want to override it, and the SecurityContextHolder ensures there is always a SecureContext (throwing an exception if it's set to null), then even with the separate SecurityContextContextHolder and SecurityContextContext, it's still way less verbose than the old classes, and just about as convenient to use as with the completely collapsed version, i.e. SecurityContextHolder.getSecurityContext().getAuthentication(); This essentially allows users to associate any information that logically belongs with the current security context with the context, and it is clear that the lifecycle of the security context is managed by Acegi Security, unlike the old classes. Ben has pointed out that you can always use a custom UserDetails implementation. This is true, but implicates AuthenticationDao and the UserDetails impl. where they shouldn't necessarilly be implicated. Colin -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - From the Source http://www.springframework.com --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Springframework-developer] Re: [Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext
I'm not using it to this extent, but the logic sounds good to me :-) Scott On Sat, 07 May 2005 17:33:34 -0400, Colin Sampaleanu wrote Colin Sampaleanu wrote: Ben Alex wrote: Pursuant to Juergen's recommendation (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), Acegi Security CVS has now had its ContextHolder and related classes removed. This functionality has been replaced by SecurityContext, which is an InheritableThreadLocal that provides a single getter/setter pair for Authentication. This is a significant change for end users, but offers a number of benefits: - Consistency with Spring core's use of a concrete ThreadLocal per functional area - SecurityContext is strictly typed (which eliminates the need for casting) - Simplified configuration as no need to specify a Context implementation for HttpSessionContextIntegrationFilter - InheritableThreadLocal used instead of ThreadLocal to simplify rich client usage (see http://forum.springframework.org/viewtopic.php?t=5004) - Elimination of handling the extra Context layer means less end user code is required Unit tests pass and I've updated the upgrade-080-090.txt in some detail. The reference guide has also been updated. It would be appreciated if developers could try the latest CVS with their applications and report any difficulties. General feedback on this change is also welcome. As I read Juergen's suggestion, I thought he was just suggesting to go away from the ContextHolder with abitlity to hold a generic Context, as it is potentially confusing as to what is going to go in there. So he suggested a SecurityContextHolder which needs to hold a SecurityContext. However, it seems to me that this simplification is much more than that, and may have gone too far, as it's all been collapsed into the one SecurityContext which is the threadlocal (effectively) and holds the Authentication. Unless I'm missing something it would still be of real use to have a real SecurityContextHolder which holds a pluggable SecurityContext. Then people can subclass that if needed to add extra data. The difference from before however is that now it is clearly security focused, and the lifecycle of the object is managed clearly by Acegi. What does everybody think? As a follow-up, from memory (it's been about a year) I believe I used a custom SecureContext to also pass along some EJB related security information (principal name, or the ejb run-as user) between different layers along with the Acegi specific info. The app in question was a mixed EJB and Spring app, using the EJB version of OSWorkflow. In general, I think if by default the user does not have to specify the actual SecurityContext implementation class unless they want to override it, and the SecurityContextHolder ensures there is always a SecureContext (throwing an exception if it's set to null), then even with the separate SecurityContextContextHolder and SecurityContextContext, it's still way less verbose than the old classes, and just about as convenient to use as with the completely collapsed version, i.e.SecurityContextHolder.getSecurityContext() .getAuthentication(); This essentially allows users to associate any information that logically belongs with the current security context with the context, and it is clear that the lifecycle of the security context is managed by Acegi Security, unlike the old classes. Ben has pointed out that you can always use a custom UserDetails implementation. This is true, but implicates AuthenticationDao and the UserDetails impl. where they shouldn't necessarilly be implicated. Colin -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - From the Source http://www.springframework.com --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/? r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list
