> I originally configured for Tomcat session clustering using multi-cast but
> then found out that the network here isn't configured for multi-cast
You don't strictly have to use multicast. Check out
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/tribes/membership/StaticMember.ht
-user@lists.jasig.org
Subject: Re: [cas-user] Stateless CAS
Hi Matt,
Is there a reason your not attempting session replication? It seems to me that
this would solve the issues your pointing out. We have been using Terracotta
for quite some time now to accomplish this type of load balancing (with no
client s
amp; Supt Team Ld
From: "Kirk, Matt" mailto:matt.k...@bskyb.com>>
Reply-To: mailto:cas-user@lists.jasig.org>>
Date: Fri, 7 Oct 2011 15:54:36 +
To: mailto:cas-user@lists.jasig.org>>
Subject: RE: [cas-user] Stateless CAS
Hi Andrew,
Thanks for the reply. The bigger
> I guess we could persist JSESSIONID and the LT
> and query for both when processing the form?
While you could do that, querying for JSESSIONID is practically
useless since the servlet API provides no way to construct or fetch a
session from its unique identifier. The spec doesn't even discuss
s
s we could persist JSESSIONID and the LT and
query for both when processing the form?
Anyway, thanks again.
Matt
From: Andrew Petro [ape...@unicon.net]
Sent: 07 October 2011 16:42
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Stateless CAS
Hi Matt,
I d
Hi Matt,
I don't see a problem with clustering the login ticket state so long as
it remains bound to a not-LT independently issued session cookie.
You said "don't ask", so I won't. Without the larger context, not sure
what's going on here.
But it's essential to prevent a password-replay-throu
Hi Scott / Marvin,
We may have a need to make CAS stateless such that in a cluster any server
could process the login form submit even if that server didn't serve the page
in the first place. (don't ask)
I was wondering what your thoughts were on this. Having a look at the code I
was wonderin
