What does "Invalid cache cookie length" mean in the cas debug logs?
For example:
[Mon Apr 09 16:17:29.340510 2018] [:debug] [pid 7828]
mod_auth_cas.c(897): [client xxx.xxx.xxx.xxx:64395] Invalid cache cookie
length for '', (expecting 32, got 0), referer:
https://
We perform regular monthly server updates, occasionally more as needed. If
we had ticket replication (which Memcached itself doesn't support) we could
do these updates during regular working hours and users wouldn't notice.
Doing maintenance off hours is an option, and how we do it for
That looks very promising! We've been using memcached for some time as a
cache but this is the first time I've ever looked for a replicated model.
Thank you!
On Tuesday, April 10, 2018 at 12:05:26 PM UTC-4, Julien Gribonvald wrote:
>
> Hi,
>
> You can use repcached for the replicated side
I think I've resolved it and it appears to be unrelated to the JCE libs.
Using jdk 1.8.162 as-is, with #crypto.policy=unlimited comment out as is
delivered.
I was using cas-management to add the jwt properties and added one too
many. When my service has the below, it works without jce error:
Hi,
You can use repcached for the replicated side with memcached, we are
using it since several years in our context and we are totally satisfied !
Thanks
Le 10/04/2018 à 17:51, Ray Bon a écrit :
Teddy,
I have not used memcached. To accomplish your goal you would need a
replicated cache.
Yan,
Accept User Agreement is shown after Login Screen form is POSTed. You can not
go back to it from Success Page because that would require resubmitting the
login form.
If you really want to be able to go back to Accept User Agreement, you could
have a link on Success Page or perform some
Teddy,
I have not used memcached. To accomplish your goal you would need a replicated
cache.
How often do you plan to restart your servers? Will your users to notice?
Ray
On Tue, 2018-04-10 at 08:07 -0700, Teddy Brown wrote:
Is it possible to get High Availability with the memcache ticket
Is it possible to get High Availability with the memcache ticket registry?
I only have these attributes configured currently and it works.
However it seems if the Memcached instance on either host is restarted (or
the host is restarted) that CAS continues to function as expected, any
Hi Mike,
Thanks for replying.
1. Cas startup says "JCE Installed: Yes " but fails to find AES??
2. Isn't unlimited the default and verified by the jsunscript test?
>From the 1.8.162 java.security file you reference:
# Cryptographic Jurisdiction Policy defaults
#
# Import and export control
The easiest way to get the latest versions of Java to use unlimited strength
algorithms is to:
Modify the file (within the Java directory):
jre/lib/security/java.security
change the commented out property, near the end of the file:
#crypto.policy=unlimited
by simply removing
Just guessing here, but I think I would first try trimming down the
principal list values from:
cas.authn.ldap[0].principalAttributeList=sn:familyName,cn:casId,givenName,mail,memberOf,xxxUID
To maybe:
cas.authn.ldap[0].principalAttributeList=cn,xxxUID
Things that always exist in every ldap
The issue got resolved once I added the postresql library into cas server
lib folder.
On Friday, April 6, 2018 at 2:58:02 PM UTC+5:30, Uxío Prego wrote:
>
> I don't know.
>
> In Maven environments I would expect the declaration of a postgresql
> artifact from the org.postgresql group ID.
>
>
12 matches
Mail list logo