Does anyone have suggestions or ideas on how we could troubleshoot this further?
On Wed, Sep 05, 2018 at 05:10:10PM -1000, Baron Fujimoto wrote:
>The service is defined as a cluster using hazelcast, but I had shut down the
>other node prior to conducting these tests. Hazelcast still seems to
The service is defined as a cluster using hazelcast, but I had shut down the
other node prior to conducting these tests. Hazelcast still seems to decode
tickets and whatnot in this degenerate cluster, but there's only a single node
available.
On Wed, Sep 05, 2018 at 03:53:29PM -0700, Travis
Hi Baron,
> ... shared session mechanism ...
I agree with Travis, without shared session some function (e.g. OAuth,
pac4j...) of CAS might not work properly.
To verified that shared session might or might not be a problem, *try
minimize your cluster to only a single node*, if that worked, then
If you are running in case servers in a cluster I think it is required to
use some shared session mechanism between the nodes for the current OAuth
implementation. This is due to the pac4j reliance on server side session
store. This might cause your issue.
On Wed, Sep 5, 2018, 1:23 PM Baron
Here are the debug logs for the client's attempt. I've just redacted some of
the potentially sensitive local info and hazelcast related entries.
2018-09-05 09:11:23,754 DEBUG
[org.apereo.cas.support.oauth.DefaultOAuthCasClientRedirectActionBuilder] -
Happy to provide more debug logs. Since the logs at DEBUG level are so verbose
I tried to excerpt what I thought would be relevant. Any suggestions on
anything in particular?
Unfortunately, while we have medium to longer term plans to upgrade to 5.3,
upgrading from 5.0 is not an option in the
