CAS Filter behavior

This page is for additional, more detailed exposition of the behvaior of CASFilter.

Handling bad tickets

CASFilter has perhaps a simplistic approach to ticket validation and handling of errors in validation. As I recall it works like this:

If the session already includes a CASReceipt

If the Session already includes a CASReceipt, indicating that a ticket has already been validated for this session, it passes the request through along the filter chain.

Caveat: and if that CASReceipt has acceptable characteristics for this filter configuration (e.g., if you map two instances of the CASFilter and one is set to require renew=true on validation, it will not accept CASReceipts set by the other instance of the filter. This is an advanced feature. If you have mapped exactly one CASFilter for your application, you can ignore this caveat).

2) If the session does not include a CASReceipt, but there is a value for the request parameter "ticket", attempt to validate that ticket. On success, set the CASReceipt and pass the request along the filter chain. On failure, throw a servlet exception.

3) If the session does not include a CASReceipt and the request does not have a value for the ticket parameter, redirect to CAS server for login.

So you're experiencing the failure mode of (2) because your sessions are expiring, taking their CASReceipts with them, and the refresh sent again the service ticket, which is no longer valid because it has already been used once.

One of the earlier CASFilter alphas included a retry behavior rather than immediate failure that would solve this problem. Perhaps it is a feature that should be implemented in the official CASFilter. It adds complexity though, which is part of why it hasn't been included thusfar.