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" <mmoay...@unicon.net> 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:scott.battag...@gmail.com] > *Sent:* Friday, April 19, 2013 12:52 PM > *To:* cas-dev@lists.jasig.org > *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" <mmoay...@unicon.net> 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:scott.battag...@gmail.com] > *Sent:* Friday, April 19, 2013 12:14 PM > *To:* cas-dev@lists.jasig.org > *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 <mmoay...@unicon.net> > 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 cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev**** > > **** > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > mmoay...@unicon.net > > **** > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev**** > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > **** > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev**** > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > mmoay...@unicon.net > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev**** > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
