Ah okay. In all honesty, I never remember what comes out in what version ;-)
-Scott On Tue, Jun 24, 2008 at 8:08 AM, Andrew R Feller <[EMAIL PROTECTED]> wrote: > Hey Scott, > > > > Thanks for the reply! > > > > I apologize as I realize I mistyped when I wrote the first question. I > meant that developers could only get a principal/username by getting it > directly from the session or by using the HttpServletRequestWrapper filter > whereas in the JA-SIG CAS 3.1 client, there is now a third option: the > AssertionHolder. I never meant that the Assertion was never available in > the session. > > > > Thanks once again!, > > Andy > > > > Andrew R Feller, Analyst > > University Information Systems > > 200 Fred Frey Building > > Louisiana State University <http://www.lsu.edu/> > > Baton Rouge, LA, 70803 > > (225) 578-3737 (Office) > > (225) 578-6400 (Fax) > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On > Behalf Of *Scott Battaglia > *Sent:* Monday, June 23, 2008 1:19 PM > *To:* Yale CAS mailing list > *Subject:* Re: CAS assertions > > > > On Mon, Jun 23, 2008 at 11:37 AM, Andrew R Feller <[EMAIL PROTECTED]> wrote: > > Two questions: > > > > *Question: What is the recommended way to access the CAS assertion > identifying authenticated users? AssertionThreadLocal filter?* > > > > I ask because I noticed a number of internal changes in the recent 3.1 > client while upgrading and realize it breaks some of our legacy code. In > the older 3.0 client, the only way to access the principal was to grab it > from the session yourself. > > As far as I recall the Assertion was always available in the session and > ultimately still is. If you merely need to access the Remote User name or > the Principal you can enable the Wrapper for the HttpServletRequest which > overrides those two methods. > > > > *Question: How likely will the AssertionHolder class be kept unchanged in > future versions? Is there any reason why an interface wasn't created for > it?* > > Its a concrete class because it has static methods so you'd be calling > the implementation anyway. ;-). There's no reason to see that it would > change since all it does is give you the Assertion for the current Thread. > Even if we made additional enhancements (a la Spring Security) the static > methods wouldn't change. > > > > I noticed the org.jasig.cas.client.validation.Assertion interface and > org.jasig.cas.client.validation.AssertionImpl, so I assume that the > interface will be consistent in the next client version. > > Yes it should. 3.0 has a dependency on the CAS Server code, purely for > convenience purposes, so we removed that dependency so that the client can > evolve on its own. Though we continue to recommend where possible that you > only rely on the standard Servlet Security points so that if you wanted to > you could change clients or security libraries (i.e. using Spring Security > instead of the CAS client directly). > > > > -Scott > > > > Thanks for the help! > > > > Andrew R Feller, Analyst > > University Information Systems > > 200 Fred Frey Building > > Louisiana State University <http://www.lsu.edu/> > > Baton Rouge, LA, 70803 > > (225) 578-3737 (Office) > > (225) 578-6400 (Fax) > > > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
