Thanks a lot for your time. I have reported the issue on Jira.
Yanis Le 26/07/2012 03:36, Scott Battaglia a écrit : > On Wed, Jul 25, 2012 at 10:04 AM, yanis aumont > <[email protected] <mailto:[email protected]>> wrote: > > Le 25/07/2012 05:25, Scott Battaglia a écrit : >> Actually, from the client's perspective, renew=true is >> *completely* dependent on whether a session exists or not. CAS >> clients manage their own session, so if they've established an >> authenticated session, as long as they consider it valid, they >> should not go back to the server to authenticate again. >> > According to my tests, removing the attribute named > CONST_CAS_ASSERTION ("_const_cas_assertion_") from the session is > enough to get the CAS client to go back to the server (since > AuthenticationFilter tests for the existence of this attribute and > not the existence of the session). But I guess it pretty much > amounts to the same as invalidating the session. > What exactly happens when a destroyed session is renewed ? As I > see it, a new ST is created by checking the client's TGT against > the server's (and reauthenticating the user if renew=true). How > far am I from the truth ? > > > Yes, invalidating the session, removing that attribute, or using the > request-only should result in the same behavior on a return to that > client. Whenever a service requests a new service ticket, the CAS > server will vend the service one, assuming there is a valid TGT. If a > service has set renew=true, it will first re-confirm the credentials > (and destroy the old ticket if the principal names do not match) and > then issue the service ticket. > > Can you open a bug report for your session-less issue? Its possible > we introduced a bug. I can investigate and get it fixed for CAS > Client 3.3 if that is the case. > > Thanks > Scott > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
