After working around this in the code, it seems principal IDs are getting cached. When I log into one instance, the other instance returns back the principal that was resolved from my original login. Is there any way to work around this?
Brodie Rao wrote: > That's right. > > As I said in my original email I'd have two differently configured CAS > instances sharing tickets. One would return mailNickname as the > principal ID to CAS clients (for Google Apps), and the other would > return username passed in (as it normally does). > > Scott Battaglia wrote: >> I'm not sure what you're trying to do. Its set to the context path >> explicitly. Are you deploying CAS under two different request context >> paths? >> >> -Scott Battaglia >> PGP Public Key Id: 0x383733AA >> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >> >> On Thu, Jul 31, 2008 at 4:24 PM, Brodie Rao <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> Actually, it looks like this is a behavior of >> org.jasig.cas.web.flow.InitialFlowSetupAction. Is there any way to >> disable or work around this behavior? >> >> Brodie Rao wrote: >> > I'm trying out the clustering idea with 3.3-RC2 and memcached, >> but I've >> > run into one snag: the two servlets aren't sharing cookies. The >> cookie >> > path is being set to the servlet path, despite p:cookiePath being >> set to >> > "/" in TG and warn cookie generators. >> > >> > I have emptySessionPath set in Tomcat, so the JSESSIONID cookies are >> > being shared, just not CASTGC/WARN. Reading up on Tomcat it looks >> like >> > it prepends the servlet path by design. Is there any way to get >> around this? >> > >> > Scott Battaglia wrote: >> >> 3.3 shouldn't have any major configuration changes from 3.2 so >> it should >> >> be an easy upgrade. We're hoping to release 3.3 soon as "final" >> I'm >> >> just waiting to hear back if anyone has any problems since I >> haven't had >> >> time to do my own testing yet. >> >> >> >> -Scott >> >> >> >> -Scott Battaglia >> >> PGP Public Key Id: 0x383733AA >> >> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >> >> >> On Thu, Jul 24, 2008 at 8:40 PM, Lucas Rockwell <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> >> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: >> >> >> >> Scott, >> >> >> >> Thanks! I will just try it with 3.3 if possible for what I >> am doing. >> >> >> >> -lucas >> >> >> >> On Jul 24, 2008, at 5:15 PM, Scott Battaglia wrote: >> >> >> >>> I'm not sure I haven't tried it. 3.2 has an AtomicBoolean >> in one >> >>> of the Tickets which can't be used in Terracotta. 3.3 changes >> >>> that (hence the version switch). >> >>> >> >>> -Scott >> >>> >> >>> -Scott Battaglia >> >>> PGP Public Key Id: 0x383733AA >> >>> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >>> >> >>> On Thu, Jul 24, 2008 at 8:02 PM, Lucas Rockwell >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> >>> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote: >> >>> >> >>> On Jul 16, 2008, at 6:56 PM, Scott Battaglia wrote: >> >>> > >> >>> > If that's not possible, is it possible to configure a >> second >> >>> > instance of >> >>> > the CAS server mounted at a different URL that shares the >> >>> same ticket >> >>> > store as the first server? That way I could point Google >> >>> Apps to that >> >>> > second instance, and keep existing applications >> pointed at >> >>> the first >> >>> > instance. >> >>> > >> >>> > CAS can share ticket stores. We've got a few options >> including >> >>> > JBossCache, MemCache, and Terracotta. The last two >> will be >> >>> as of 3.3. >> >>> >> >>> Does this means that if I were to try Terracotta with >> CAS 3.2.x, I >> >>> would be beating my head against the wall? >> >>> >> >>> -lucas > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
