On Thu, Jan 31, 2013 at 2:57 AM, Fredrik Jönsson <[email protected]> wrote:
> I'll start a new thread on this. The thread on CAS-1255 got me started on
> this, and my worries are somewhat confirmed. Or am I missing something? The
> number of layers of indirection in this part of the code make the logic
> somewhat difficult to follow so that may very well be the case.
No doubt, and thanks for looking into this.
There's a bit of magic down in AbstractDistributedTicketRegistry and
its set of private static TicketDelegator classes. Most (all?) of the
distributed ticket registries extend this class. If you look at
TicketGrantingTicketDelegator, you'll see the expire() method that
will ultimately fire the callbacks
(TicketGrantingTicketImpl.logOutOfServices) regardless of
TicketRegistry type.
So...for calls to cas/logout when SLO is turned on (not recommended
:), and you are using the DefaultTicketRegistry or an impl of
AbstractDistributedTicketRegistry (e.g. JpaTicketRegistry, Ehcache,
etc) the SLO callbacks will be fired. CASImpl first calls
ticket.expire() and then calls ticketRegistry.deleteTicket() in
CASImpl.destroyTicketGrantingTicket().
This still leaves open the question of cascading to PGT/PT.
Separately, but related is the issue that some TicketRegistries call
expire() when "cleaning up" (JPA) and some TicketRegistries do not
(Ehcache). So you will also have SLO callback being fired when the
TGT has timed-out and the Cleaner decides to run...whenever that is.
>
> This is the JpaTicketRegistry implementation:
>
> @Transactional(readOnly = false)
> public boolean deleteTicket(final String ticketId) {
> final Ticket ticket = getRawTicket(ticketId);
>
> if (ticket == null) {
> return false;
> }
>
> if (ticket instanceof ServiceTicket) {
> removeTicket(ticket);
> log.debug("Deleted ticket [{}] from the registry.", ticket);
> return true;
> }
>
> deleteTicketAndChildren(ticket);
> log.debug("Deleted ticket [{}] and its children from the registry.",
> ticket);
> return true;
> }
>
> This is the contract in TicketRegistry.
>
> /**
> * Remove a specific ticket from the registry.
> *
> * @param ticketId The id of the ticket to delete.
> * @return true if the ticket was removed and false if the ticket did not
> * exist.
> */
> boolean deleteTicket(String ticketId);
>
> It says absolutely nothing about deleting related tickets. I would rather
> claim that is says to specifically delete the ticket with the given id, not
> any other ticket with some other id, and that the current JpaTicketRegistry
> implementation is broken given the existing contract. So, what's the expected
> behavior of a proper ticket registry here?
Well, I think that is mostly up to the TicketRegsitry....JPA in this
case is eagerly "cleaning up" what are now invalid tickets (since the
root has been expired). Ehcache does not do this, since it relies on
cache settings for "clean up".
> This does have consequences for how e.g. PGTs behave depending on selected
> ticket storage and this makes me uncomfortable.
I don't believe this is the case. Once the root TGT is invalid the
whole chain is invalid, regardless if the PGT is still in the Registry
(in an expired state). Take a look at AbstractTicket.isExpired().
Best,
Bill
>
> I believe, e.g., MemcacheTicketRegistry does not behave like this.
>
> Best regards,
> /Fredrik
>
>
> --
> 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
