If you search our archives a little bit, you will find some details on ways to reconfigure the Spring Web Flow such that it doesn't require sessions. If you do that you should ensure that your users use relatively recent browsers that won't have any issues with the back button resubmitting POSTs (such as the credentials you provided).
-Scott On Wed, Mar 5, 2008 at 5:56 AM, Arnaud Lesueur <[EMAIL PROTECTED]> wrote: > Step 2 is required for load balancing without a frontal load balancer > which handles sticky sessions in front (the login webflow is using tomcat > session) > > In case of a simple failover, this step is not mandatory. > > Regards, > > -Arnaud > > > On Wed, Mar 5, 2008 at 9:49 AM, Ina Müller < > [EMAIL PROTECTED]> wrote: > > > Hello, > > > > we want to use CAS in a HA solution, so I had a look at > > http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS. > > > > It describes three steps: > > 1.- Ticket Uniqueness > > 2.- Tomcat Session Replication > > 3.- Ticket Cache Replication > > > > Steps 1 and 3 are clear. But for what scenario do I need step 2? > > What CAS specific stuff in session state has to be replicated? > > Isn't it enough to distribute the TGTs among the CAS servers to have a > > failover solution? > > > > Or lets restate the question: if I omit step 2, what can go wrong in > > case of failover to another server? > > > > Thank you for your help, Ina > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > -- > Arnaud Lesueur > > LinkedIn: http://www.linkedin.com/in/lesueur > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
