David, You'd have to implement a Ticket Registry that persists them (we have a BerkleyDb example in CAS). However, if you are using the distributed JBoss Cache implementation, if you take one down and bring it back up I would think (in theory) that it should receive all of the information. If you take them all down at the same time, well.... :-)
-Scott On 9/7/07, David Pham <[EMAIL PROTECTED]> wrote: > > Thanks for the input Scott. > > Additionally this question is somewhat related to session replication. > Is there also a way to set up persistent storage for the ticket granting > cookies? My understanding is that CAS stores the tickets in-memory but with > the experiment I'm doing, I will be taking CASes online and offline at timed > intervals and it would be ideal if I can somehow dump the ticket registry to > a database or a flatfile. > > Regards, David > > On 9/6/07, Scott Battaglia <[EMAIL PROTECTED]> wrote: > > > > On 9/6/07, David Pham <[EMAIL PROTECTED]> wrote: > > > > > > Scott, > > > In regards to replicating the client-side cookies I understand that > > > in order to make the cookie visible to all the CASes in the cluster, we > > > have > > > to configure them to be on the same domain by modifying the cookieDomain > > > property. But what if our CASes are not in a domain? In other words, > > > each > > > of my CAS is housed on its own host computer and the domain is simply " > > > localhost.localdomain" where the hosts know of each other because they > > > belong to the same private network. > > > > > > There should be some domain that points to both of those servers (how > > else would your users access CAS as a single "service"?). That domain > > should be what is set. > > > > -Scott > > > > Regards, David > > > > > > On 8/29/07, Scott Battaglia <[EMAIL PROTECTED]> wrote: > > > > > > > > Guys-- > > > > > > > > Depending on how you configure CAS, various items can be replicated. > > > > > > > > If you use a Distributed Ticket Registry, such as JBossCache (or any > > > > custom one such as a JDBC), the Ticket Granting Tickets and Service > > > > Tickets > > > > are replicated amongst the CAS servers. Their updated state should > > > > also be > > > > replicated amongst CAS servers the instant (well conceptually, the > > > > instant) > > > > they are modified. > > > > > > > > If you've configured Tomcat (or your container) for session > > > > replication, then the Tomcat sessions should be replicated. Tomcat > > > > sessions > > > > only contain information relevant to the initial Spring Web Flow login > > > > process (if you don't replicate Tomcat sessions then you need to use > > > > sticky > > > > sessions or modify the Web Flow configuration to use client side > > > > storage). > > > > > > > > Client Side information is still maintained within the browser. The > > > > cookie that holds the Ticket Granting Ticket ID should be sent to > > > > either CAS > > > > server, assuming the domain/path information is specified correctly (and > > > > since the registry is duplicated, all tickets should be accessible). > > > > The > > > > same thing can be said for the "warn" cookie. > > > > > > > > -Scott > > > > > > > > On 8/29/07, Andrew R Feller < [EMAIL PROTECTED]> wrote: > > > > > > > > > Andrew, > > > > > > > > > > > > > > > > > > > > Yes, I believe we are saying the same thing. The distinction I > > > > > was trying to bring up was client-side cookies stored in your web > > > > > browser > > > > > versus server-side sessions. There is no way, I am aware of, to > > > > > replicate > > > > > client-side cookies on a user's web browser. I know the ticket > > > > > granting > > > > > ticket's cookie should be scoped a specific domain/subdomain that > > > > > only the > > > > > CAS servers can see and thus available to all of them. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > Andrew R Feller, Analyst > > > > > > > > > > Subversion Administrator > > > > > > > > > > University Information Systems > > > > > > > > > > Louisiana State University > > > > > > > > > > [EMAIL PROTECTED] > > > > > > > > > > (office) 225.578.3737 > > > > > ------------------------------ > > > > > > > > > > *From:* [EMAIL PROTECTED] [mailto: > > > > > [EMAIL PROTECTED] *On Behalf Of *Andrew Petro > > > > > *Sent:* Tuesday, August 28, 2007 6:47 PM > > > > > *To:* Yale CAS mailing list > > > > > *Subject:* what is replicated in CAS clustering > > > > > > > > > > > > > > > > > > > > Andrew, > > > > > > > > > > > client-side cookies are not replicated; > > > > > > only Tomcat's session data and ticket registries are. > > > > > > > > > > I'm not sure I understand the distinction. > > > > > > > > > > To the extent that CAS uses session cookies, these will be > > > > > applicable across clustered CAS server instances in the case where a > > > > > fronting load balancer makes them all appear to the browser to be the > > > > > same > > > > > hostname. Session data will be as you say can be replicated across > > > > > the > > > > > cluster via Tomcat session replication. What makes a jsessionid > > > > > cookie > > > > > interesting is that it keys into that server-side session data, which > > > > > so > > > > > long as it is exclusively composed of serializable [1] objects can be > > > > > clustered across the Tomcats. > > > > > > > > > > The ticket granting cookie is valid by virtue of its bearing a > > > > > valid "Ticket Granting Ticket". Ticket granting tickets are stored > > > > > in the > > > > > ticket registry, and so clustering of the ticket registry accomplishes > > > > > making a ticket granting cookie applicable across the cluster. > > > > > > > > > > User preference cookies (e.g. indicating the preference not to be > > > > > transparently signed on) are not dependent on server-side state, so > > > > > there's > > > > > nothing to cluster. I'm not sure what it would mean to replicate > > > > > these > > > > > cookies, but in any case they should work the same across clustered > > > > > CAS > > > > > nodes. > > > > > > > > > > Are we agreeing in all details and just saying the same thing > > > > > differently, or have I missed something here? > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > > [1] sort of > > > > > > > > > > > > > > > > > > > > > > > > > 2) Within a cluster of CAS servers, how often does the ticket > > > > > data get replicated? If one peer server goes offline then online, > > > > > does the > > > > > session data (as well as the ticket data) get replicated immediately > > > > > or is > > > > > there an interval at which this happens? I am assuming there must > > > > > be some > > > > > handshaking process between the new server and existing servers thus > > > > > allowing the new server to sync up with the cluster. > > > > > > > > > > * * > > > > > > > > > > *[Andrew R Feller] * > > > > > > > > > > *In the scenario of one node dropping from the cluster and > > > > > reappearing, the JBoss Cache will re-establish its ticket registry > > > > > whenever > > > > > it successfully joins the cluster; there is no "waiting time". > > > > > Cluster > > > > > membership discovery can either be multicast or unicast depending > > > > > upon your > > > > > networking situation. As far as frequency of ticket replication, > > > > > that is a > > > > > function of both JBoss Cache and Tomcat session replication. > > > > > However, I > > > > > believe Claudio is mistaken in that client-side cookies are > > > > > notreplicated; only Tomcat's session data and ticket registries are. > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) Within a cluster of CAS servers, how often does the ticket > > > > > data get replicated? If one peer server goes offline then online, > > > > > does the > > > > > session data (as well as the ticket data) get replicated immediately > > > > > or is > > > > > there an interval at which this happens? I am assuming there must > > > > > be some > > > > > handshaking process between the new server and existing servers thus > > > > > allowing the new server to sync up with the cluster. > > > > > > > > > > > > > > > > > > > > The ticket replication is managed through two different > > > > > mechanisms: client-side cookies are replicated using the cluster > > > > > feature of > > > > > the application server (tomcat), while the cas ticket registry is > > > > > replicated > > > > > among the cluster nodes using some other "pluggable" method. The > > > > > document > > > > > you read explains how to set up this through the jboss-cache > > > > > libraries. In > > > > > both cases, the syncronization method can be configured, but for cas > > > > > cluster > > > > > to work properly it should be set in syncronous mode, which means > > > > > that data > > > > > is replicated between the nodes each time it's modified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Yale CAS mailing list > > > > > cas@tp.its.yale.edu > > > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > > > > > > > > > > > -- > > > > -Scott Battaglia > > > > > > > > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > > _______________________________________________ > > > > Yale CAS mailing list > > > > cas@tp.its.yale.edu > > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > > > _______________________________________________ > > > Yale CAS mailing list > > > cas@tp.its.yale.edu > > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > > > > > > -- > > -Scott Battaglia > > > > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > > > _______________________________________________ > > Yale CAS mailing list > > cas@tp.its.yale.edu > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > _______________________________________________ > Yale CAS mailing list > cas@tp.its.yale.edu > http://tp.its.yale.edu/mailman/listinfo/cas > > -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list cas@tp.its.yale.edu http://tp.its.yale.edu/mailman/listinfo/cas
