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 p.bo...@centrum.cz > 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 cas-user+unsubscr...@apereo.org. 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.
