Okay, the last issue was due to ticket taking more than 10sec to validate. That is resolved.
One thing I did not notice before is that I'm seeing errors in my logs that TGT already exist so I get a unique constraint violation when inserting into postgres db. Would this be due to *cas.ticket.tgt.core.only-track-most-recent-session=false ?* On Sunday, August 20, 2023 at 2:03:35 AM UTC-5 Pablo Vidaurri wrote: > Thanks Petr, > > setting *cas.ticket.tgt.core.only-track-most-recent-session=false *did > help, all calls are working now with exception of 1. I will dig into that > one to see if it is doing something different. > > -psv > > On Saturday, August 19, 2023 at 12:52:27 PM UTC-5 [email protected] > wrote: > >> Hi Pablo, >> >> > ... Could many request for ST's be clobbering other tickets before the >> others get validated first >> >> The answer seems YES, provided you use CAS v6.6.0-RC4+ and create ST's >> for the same base URL - see https://github.com/apereo/cas/pull/5688 >> which I have created recently. So the 1 way to "fix" this is to set " >> *cas.ticket.tgt.core.only-track-most-recent-session=false*", the other >> is to change the corresponding CAS Java class. >> >> Unfortunately, authors of CAS haven't responded at all since this problem >> was firstly discovered here >> <https://github.com/apereo/cas/commit/901d8895f99dd72d72973a951cd2d8876c6ac6ff#r87291886>... >> >> >> >> Petr >> >> On Saturday, 19 August 2023 at 07:09:22 UTC+2 Pablo Vidaurri wrote: >> >>> Testing CAS 6.6.8. >>> >>> I have ST persisted to postgres db. >>> >>> User logs in, i see ticket created in CAS logs. Then I see in browser a >>> redirect with SAMLart query parameter with the same ticket and a 500. >>> >>> CAS logs then show ticket is invalid even though ST was created with the >>> same second and this is the first time being used: >>> WHO: audit:unknown >>> WHAT: >>> {ticket=ST-AAHJiT+kQbIMdHbOBFu0HYQw8IWXSOsHmkv0HGmNGYU6zeAGd04MwG8u, >>> service=https://www.xxx.com/myapp/api/user/profile} >>> ACTION: SERVICE_TICKET_VALIDATE_FAILED >>> APPLICATION: CAS >>> WHEN: Fri Aug 18 13:54:51 MST 2023 >>> CLIENT IP ADDRESS: xxx.xx.xxx.xxx >>> SERVER IP ADDRESS: www.xxx.com >>> >>> And throws back a denied Saml response: >>> >>> [<?xml version="1.0" encoding="UTF-8"?><saml1p:Response >>> xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" >>> InResponseTo="_ec2e5252a76f05a00f75d5b7a97f5a65" >>> IssueInstant="2023-08-18T20:54:29.255Z" MajorVersion="1" MinorVersion="1" >>> ResponseID="_8c3c28ff013ed82e1dc573a02b7a949b"> >>> <saml1p:Status> >>> <saml1p:StatusCode Value="saml1p:RequestDenied"/> >>> <saml1p:StatusMessage>Ticket >>> 'ST-AAHJiT+kQbIMdHbOBFu0HYQw8IWXSOsHmkv0HGmNGYU6zeAGd04MwG8u' not >>> recognized</saml1p:StatusMessage> >>> </saml1p:Status> >>> </saml1p:Response> >>> ] >>> >>> I have about 6 async API calls behind CAS and first call to them trigger >>> a service ticket. What could be causing this? I thought maybe there was a >>> delay so I tried using in Memory db for ticket but issue is still there. >>> Could many request for ST's be clobbering other tickets before the others >>> get validated first? >>> >>> -psv >>> >> -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- 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/a80dbc10-fadd-4639-88ac-318d57c066f4n%40apereo.org.
