Colin Sampaleanu wrote:
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.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?
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
