OK, but even in that context I am not sure what to make of the current behavior. Does it make sense to imply that if a TGT grants an ST, that ST is "used" once? Or if the ST is just being checked for a service match, does it make sense to call it used? I am not sure that it does.
Shouldn't we decide on an actual and clear definition of what used in the ticketing context is? I tend to align that more with validation calls and how then it might be relevant to the expiration policy, (which is what the current behavior seems to slightly imply), but perhaps, there can be a more accurate description? If the ticket state is managed by something else, and the ticket itself has no way of knowing what that something is or how it's going to use the ticket, it seems confusing to me let the ticket itself be responsible for figuring out whether or not it's "used". Makes sense? To put that in better context, it's not clear why the below test would fail: https://gist.github.com/mmoayyed/5436911 From: Scott Battaglia [mailto:[email protected]] Sent: Sunday, April 21, 2013 2:33 AM To: [email protected] Subject: RE: [cas-dev] Question on AbstractTicket.updateState() Successful or failed validation is irrelevant to state update. State is updated when a ticket is used. A ticket itself determines when it is used. On Apr 20, 2013 11:52 AM, "Misagh Moayyed" <[email protected]> wrote: Well, I think we can reasonably come up with the proper API to not break encapsulation as much and yet actually be able to update the ticket state after a validation event. Initially, I just wanted to confirm that the behavior currently as far as ticket state goes does seem to want to make a number of unwarranted assumptions that ultimately affects the expiration policy negatively. If this analysis seems correct, we can start brainstorming about how to better approach this. Part of the issue is that tickets currently have no way of determining a validation event and a successful one for that matter. All that logic happens outside and carried on by CASImpl and others. So it seems like we either have to expose the right hooks into the ticket api or somehow send the signal over that the ticket is actually successfully validated and its count and status can be incremented, etc. I am considering a number of options, but do certainly appreciate suggestions and feedback. Another possible approach might be to delegate the ticket statement management to a different component and not have the ticket itself remain responsible for it? From: Scott Battaglia [mailto:[email protected]] Sent: Friday, April 19, 2013 12:52 PM To: [email protected] Subject: RE: [cas-dev] Question on AbstractTicket.updateState() Only tickets can update their state. Nothing else. On Apr 19, 2013 3:49 PM, "Misagh Moayyed" <[email protected]> wrote: No, because that validation does happen down the line. If the call to updateStatus() was done outside of isValidFor() somewhere in CASImpl when all checks pass that would have been clearer. ST.isValidFor() could return false if the match fails and yet the state is updated which subsequently could cause the exp policy to kick in and consider the ticket expired. For STs, I think the status update should happen inside CASImpl. For TGTs, possibly when the SSO session is established? Makes sense? From: Scott Battaglia [mailto:[email protected]] Sent: Friday, April 19, 2013 12:14 PM To: [email protected] Subject: Re: [cas-dev] Question on AbstractTicket.updateState() The state is updated when its validated. Isn't that your #2? -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Fri, Apr 19, 2013 at 3:09 PM, Misagh Moayyed <[email protected]> wrote: Team, Looking at CAS ticket API and trying to better review the ticket expiration policy, I stumbled upon the updateState() [1] method call that I am not sure I am understanding correctly. This method is called in two areas: 1. When TGT grants an ST http://bit.ly/ZEfGFB 2. When ST attempts to ensure a match between the service and the incoming service to validate http://bit.ly/13wXXYB updateState() does the following: 1. Records the previous last used time 2. Records the last used time 3. Updates the ticket usage count My question is: shouldn't the ticket state be updated when the ticket is validated? Such that the expiration policy would then be able to determine that the ticket is "actually" used once based on its update count? Misagh [1] http://bit.ly/11sfyu1 -- 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-dev -- 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-dev -- 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-dev -- 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-dev -- 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-dev -- 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-dev -- 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-dev
