Thanks for the sugestion, we try but it no change.
At the end, even when it was de same error text
"[org.apereo.cas.util.function.FunctionUtils] - <SAML request could not be
determined from session store" it was't related to the conf, we manage to
replicate the error in only one node infractrusture, so we look deeper and
found a problem in the use of getSamlAuthnRequest() func that we use in a
release attributes groovy script that only fails when you access in a
specific order... We have a little complex multi protocol deploy.
Cheers.
El sábado, 7 de octubre de 2023 a las 20:13:57 UTC+2, M. Ebrahimi escribió:
> Hi
> Did you try BROWSER_SESSION_STORAGE? This seems to have solved the
> problem for us.
>
> On Wednesday, October 4, 2023 at 4:05:18 PM UTC+3:30 Juan Manuel Díaz
> Nevado wrote:
>
>> Hi,
>>
>> We are experiencing the same problem on our installation of cas 6.6.11.
>>
>> Did you manage to correct it?
>>
>> Now I am where you comment in your message, seeing that changing
>> cas.authn.saml-idp.core.session-storage-type=TICKET_REGISTRY does not seem
>> to change anything
>>
>> Any hint will be appreciated thanks.
>>
>> El martes, 18 de octubre de 2022 a las 10:10:58 UTC+2, Sven Specker
>> escribió:
>>
>>> Hi!
>>>
>>> I upgraded from CAS 6.1.x to 6.5.9 and got that to run with little
>>> trouble (apart from per-Service-CORS).
>>>
>>> Now I am getting reports that people cannot log in to a SAML-service and
>>> looking in the log, I see
>>>
>>> java.lang.IllegalArgumentException: SAML request or context could not be
>>> determined from session store
>>>
>>> My setup is
>>>
>>> HA-Proxy->2 tomcats->REDIS Sentinel.
>>>
>>> The proxy is only balancing and setting cookies while the sentinel is of
>>> course identical for both tomcats, just as their crypto-setup (which i
>>> did not change from 6.1).
>>>
>>> I stumbled across a similar problem of another CAS-User and proceeded to
>>> set
>>>
>>> cas.authn.saml-idp.core.session-storage-type=TICKET_REGISTRY
>>>
>>> Alas, that did not really work either.
>>>
>>> Then i deactivated one of the tomcats to check if there is voodoo
>>> happening if requests are checked by a different tomcat than the one
>>> issuing them.
>>>
>>> Did not change the errors.
>>>
>>> Since there is no hint in the error (the exception is not very
>>> helpful..), I wonder if anyone out there has similar trouble and can
>>> enlighten me.
>>>
>>> Best regards,
>>>
>>> Sven Specker
>>> --
>>> __________________________________________________________________
>>> *** Sven Specker -- University of Frankfurt Computing Center ***
>>> *********** UNIX System Administration (Auth/IDM) ****************
>>> ***** spe...@rz.uni-frankfurt.de [Phone (+49)-69-798-15188
>>> <+49%2069%2079815188>] *****
>>> ******************************************************************
>>> __________________________________________________________________
>>> Johann Wolfgang Goethe Universitaet
>>> - Hochschulrechenzentrum -
>>> Theodor W. Adorno-Platz 1 (PA-1P16)
>>>
>>> D-60323 Frankfurt/Main
>>> __________________________________________________________________
>>> ______________ TeX-users do it in {groups}________________________
>>>
>>
--
- 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/c3b0466e-2996-4340-9825-f84c6191b164n%40apereo.org.
