Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Parent TGT should be (optionally) updated when child PGT is used

Description

See https://groups.google.com/forum/#!topic/jasig-cas-user/tO0judeH2R0 for discussion.

The basic idea is to create a new interface (e.g. TicketGrantingTicketUpdatePolicy) which would have a single method that returns a list of tickets whose last accessed timestamp should be updated. The default implementation of this interface would a list containing only the ticket granting ticket that is actually granting the new service ticket. The alternate implementation could return a list containing the current ticket granting ticket and all of its ancestors. Then instead of just calling updateState() for itself, TicketGrantingTicketImpl can call updateState() for every element in the list returned by the TicketGrantingTicketUpdatePolicy implementation.

As noted in the dicussion, there are some issues with this approach with serialization-based ticket registries, which will need to be addressed.

Environment

None

Activity

Show:

Misagh MoayyedJuly 15, 2014 at 7:10 AM

All Open JIRA issues are now moved to Github, and tracked under Github Issues. The migration is now complete. Please use Github issue tracking to file and track issues. JIRA issues will be closed.

The URL address for Github issues of the CAS project is:
https://github.com/Jasig/cas/issues

William G. Thompson, Jr.November 4, 2013 at 1:41 PM

If this discussion belongs in the Jira issue instead of the mailing list, please let me know and I'll move it there.

I spent a little bit of time trying out the potential solution that's under discussion, and I ran into a issue when trying to update the parent ticket state(s) – namely, that the method for updating the state is in TicketState rather than TicketGrantingTicket.

The easy way out is, of course, make the UpdatePolicy deal in a list of TicketGrantingTicketImpl rather than TicketGrantingTicket, but I suspect that would not pass muster on a pull request, as I assume Ticket and TicketState are different interfaces for a reason. Is a refactoring of these two interfaces in order?

There's also the issue with serialized ticket registries, although I have no idea how I'd approach that (and I'd love to hear ideas that I could explore).

Thanks,
Rich

Marvin AddisonOctober 30, 2013 at 1:22 PM
Edited

Agree with ~jleleu, let's get some working code to start negotiating a solution and where it should go.

Jérôme LELEUOctober 7, 2013 at 2:55 PM

I'm still reluctant for this on 4.0.
However, it looks like you have already a good idea of the implementation : maybe a pull request would help decide what to do ?

William G. Thompson, Jr.September 25, 2013 at 12:46 PM

Depends on the change set. This is an issue that has come fairly frequently with deployments that make extensive use of proxy tickets. If it is possible to craft an pull that does this in a way that is consistent with the release strategy it would be makes sense to get this in 3.5.x and 4.x.

Proposal Declined

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Priority

Created September 5, 2013 at 6:46 PM
Updated July 15, 2014 at 7:10 AM
Resolved July 15, 2014 at 7:10 AM