I had the same issue before. By tracing the source code, CAS 4.2 would 
check if the time of ticket validation - time of ticket created < a 
threshold on milliseconds level. Since the two times are very close 
(actually 0ms!), the ticket will be considered as invalid and discarded. 
Then I set the threshold as -1 as work around:

<bean id="grantingTicketExpirationPolicy"
class="org.jasig.cas.ticket.support.ThrottledUseAndTimeoutExpirationPolicy"
p:timeToKillInMilliSeconds="10800000"
p:timeInBetweenUsesInMilliSeconds="-1" />

Then it got solved. IMHO there should not be such check on the first 
validation and shouldnt compare the time in ms. Sadly, I check later 
releases of 4, it was not fixed yet...

On Wednesday, February 8, 2017 at 3:24:39 AM UTC+8, Melissa Floyd wrote:
>
> Thank you for your feedback.  That does make sense.  We wouldn't have that 
> issue on our current testing server however it is making me wonder if its 
> possible that expiration policy is somehow discarding the ticket during the 
> validation process before its validated.  I have looked at the 
> configuration but will look again to see if I am missing something there.
>
> Thanks again,
> Melissa
>
> On Mon, Feb 6, 2017 at 6:48 AM, Menno en Erla Avegaart <[email protected] 
> <javascript:>> wrote:
>
>> I had this problem with a clustered CAS where the time of one of the 
>> servers was out of sync. The created ticket was immediately discarded by 
>> the other server, because it seemed too old.
>>
>>
>> Op vrijdag 3 februari 2017 19:36:14 UTC+1 schreef Melissa Floyd:
>>>
>>> Hi Everyone,
>>>
>>> We have setup an application to reply on a passed in proxy ticket to 
>>> authenticate through CAS.  An INVALID_TICKET XML response is received by 
>>> the phpcas because the ticket is not recognized.  However, when we look in 
>>> the CAS logs in debug mode, we can see clearly that the 
>>> DefaultTicketRegistry actually does find the ticket and removes it from the 
>>> registry.  However for some reason, immediately after, we see 
>>> DefaultTicketRegistry searching for the ticket again.  Of course at this 
>>> point, since the ticket has already been removed, 
>>> CASAuthenticationServiceImpl reports that it cannot be found, and CAS 
>>> returns the INVALID_TICKET response.  
>>>
>>> Does anyone know what would potentially cause 2 validation calls to 
>>> occur on the same ticket during proxy authentication ?
>>>
>>> Thanks for your help,
>>> Melissa
>>>
>> -- 
>> - CAS gitter chatroom: https://gitter.im/apereo/cas
>> - CAS mailing list guidelines: 
>> https://apereo.github.io/cas/Mailing-Lists.html
>> - CAS documentation website: https://apereo.github.io/cas
>> - CAS project website: https://github.com/apereo/cas
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "CAS Community" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/apereo.org/d/msgid/cas-user/cb1e60dd-242d-4a63-89b8-150dcaf6ea00%40apereo.org
>>  
>> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/cb1e60dd-242d-4a63-89b8-150dcaf6ea00%40apereo.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

-- 
- CAS gitter chatroom: https://gitter.im/apereo/cas
- CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
- CAS documentation website: https://apereo.github.io/cas
- CAS project website: https://github.com/apereo/cas
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/7ae1dd81-4801-4dc5-b815-a2f8bbdadc7a%40apereo.org.

Reply via email to