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
