That is what I thought when we set it up with just sticky sessions & JPATicketRegistry. However, if you get a ST from server A and try to validate it on server B it returns "unrecognized ticket". I have tested this using the DotNetCasClient and also using a manual test in the browser, going to server A, getting a ST, validating that ST on server B.
Scott, where is the spring webflow session vs. request configured at? Thanks, On Thu, Sep 24, 2009 at 9:23 AM, Marvin Addison <[email protected]>wrote: > > Can anyone enlighten me as to why more is needed than the > > JPATicketRegistry? > > Nothing more is needed. We use neither option Scott mentioned and are > happy with our JPATicketRegistry solution on active-active clustered > CAS in production. Sticky sessions are required for proper Webflow > management for the initial authentication process (e.g. login form), > but since ticket state is stored in the database, you can always > properly reinitialize the correct authenticated state for a new > Webflow session. I believe there may be some edge cases that could > present minor irritation, but the additional configuration to address > them is not warranted in my opinion. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
