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 Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
