Hello I focused on the test environment, which has fewer users, making it easier to trace a particular user session. I was finally able to track down the meaning of this exception in my logs, although the results was not what I expected.
In the cas.log for 11/2/2015 on our TEST environment, I found references to a Ticket Granting ticket, TGT-7-q699ZXxfKNPnHU1X9d3zBXfOKwXfLT ZLaWQXplYhxX6pv9gauL-cas-test.alaska.edu <http://tgt-7-q699zxxfknpnhu1x9d3zbxfokwxfltzlawqxplyhxx6pv9gaul-cas-test.alaska.edu/> Today, 11/3, that ticket was still in memory so when the same user logged in, it first attempted to get that ticket, found the FlowSession had expired, then issued another ticket. This is creating a phenomenon whereby a user gets the successful login page, rather than the target URL. If the user backspaces or tries to enter the URL, a new TGT is granted, followed by the service ticket. I confirmed with the EAS staff member that in fact he did received that message today when he logged into BEIS TEST. The parameters on this system are not set for over 24 hours. Why is that ticket still active in memory? Here are the parameters as they are currently set: <!-- Expiration policies --> <util:constant id="SECONDS" static-field="java.util. concurrent.TimeUnit.SECONDS"/> <bean id="serviceTicketExpirationPolicy" class="org.jasig.cas.ticket. support.MultiTimeUseOrTimeoutExpirationPolicy" c:numberOfUses="1" c:timeToKill="${st.timeToKillInSeconds:30}" c: timeUnit-ref="SECONDS"/> <!-- TicketGrantingTicketExpirationPolicy: Default as of 3.5 --> <!-- Provides both idle and hard timeouts, for instance 2 hour sliding window with an 8 hour max lifetime --> <bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket. support.TicketGrantingTicketExpirationPolicy" p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:30000}" p:timeToKillInSeconds="${tgt.timeToKillInSeconds:7200}"/> Linda Toth University of Alaska - Office of Information Technology (OIT) - Identity and Access Management 910 Yukon Drive, Suite 103 Fairbanks, Alaska 99775 Tel: 907-450-8320 Fax: 907-450-8381 [email protected] | www.alaska.edu/oit/ On Thu, Nov 3, 2016 at 1:48 PM, Linda Toth <[email protected]> wrote: > I think this issue contributed to CAS failing 10/31. I noticed that it > was opened as early as 2012 for 3.5.1, and there were several other reports > of the same issue. > > I have been searching through the forums to find suggested parameter > settings to resolve the issue. Does anyone have any insight into this? > > Linda > > > Linda Toth > University of Alaska - Office of Information Technology (OIT) - Identity > and Access Management > 910 Yukon Drive, Suite 103 > Fairbanks, Alaska 99775 > Tel: 907-450-8320 > Fax: 907-450-8381 > [email protected] | www.alaska.edu/oit/ > > -- - 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/CAOi1v6OktwQ1pVU1jWcStbTJLXFnTFL%2Bu4d7Fyvc%3DkGgEa-Etw%40mail.gmail.com.
