Hi Yasushi In your serverl.xml have you added the jvmroute to the Engine?
i.e. <Engine name="Catalina" defaultHost="localhost" jvmRoute="1"> Andrew On Tue, Jun 22, 2010 at 2:50 PM, Okubo, Yasushi (TSD) <yasushi.ok...@takedasd.com> wrote: > Hi Andrew > > Thank for your post. When I checked the session id from firefox, sso session > id [jsessionidsso] does not have jvmroute info, but only jsessionid has > jvmroute. So, session replication upon failover is working fine, but > singlesionon upon failover is not working on tomcat 6.0.x (including 6.0.26). > > yasushi > > -----Original Message----- > From: Andrew Bruno [mailto:andrew.br...@gmail.com] > Sent: Monday, June 21, 2010 9:18 PM > To: Tomcat Users List > Subject: Re: question for sso session replication in tomcat 6.0.26 > > Looking at the code I think this is wrong > > if (!_ssoSessionId.contains("." + jvmRoute)) { > _ssoSessionId += "." + jvmRoute; > response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId)); > } > > The original sessionId will already have the "."+_any_other_jvmRoute > included, so you need to substring it, and append the new jvmRoute. > > _ssoSessionId= _ssoSessionId.substring(0, _ssoSessionId.indexOf(".")) > > and then add > > _ssoSessionId += "." + jvmRoute; > > AB > > On Tue, Jun 22, 2010 at 1:03 PM, Okubo, Yasushi (TSD) > <yasushi.ok...@takedasd.com> wrote: >> Hi experts >> >> >> >> I found this old email from archive in TC 5.5.23. >> >> Does this problem still exist in tomcat 6.0.x or 6.0.26? >> >> >> >> When failover occurs, sso session id is updated with new number after >> forcing a user to relogin to the application since sso session id is not >> replicated and rewritten correctly. Could someone explain what is >> expected in current tomcat 6.0.x cluster upon failover? Should sso >> session id is replicated correctly in tomcat 6.0.x? >> >> >> >> Thanks, >> >> yasushi >> >> >> >> >> >> >> >> ROOKIE wrote: >> Hi, >> I have a problem with tomcat cluster + mod_proxy load balancer : >> >> We have a main app which authenticate itself to a webapp and from this >> app one >> can launch embedded apps which use the SSO cookie to access other >> webapps on >> the server (Single-Sign-On for the user). >> >> Things are working perfectly for the normal cookie but not for the sso >> cookie. >> >> >> The problem I have is that tomcat does not replicate SSO sessions so >> when these embedded apps route through the load balancer we get 401s on >> all the other cluster members except the one which actually generated >> the SSO cookie. >> >> I wanted to know if we can edit the SSO cookie generated by tomcat to >> also >> contain the jvmRoute parameter so that the load balancer directly goes >> to the >> correct cluster member. >> >> >> I tried doing this in my code by fetching the SSO cookie and appending >> to it >> the jvmRoute as follows : >> >> HttpServletRequest request = >> (HttpServletRequest)Security.getContext(HttpServletRequest.class); >> HttpServletResponse response = >> (HttpServletResponse)Security.getContext(HttpServletResponse.class); >> if(request != null) { >> String jvmRoute = "Vinod_Cluster_1"; // as mentioned in >> server.xml >> Cookie[] cookies = request.getCookies(); >> for(int nc=0; cookies != null && nc < cookies.length; nc++) >> { >> if(_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) { >> _sessionId = cookies[nc].getValue(); >> } >> >> else if(_SSO_SESSION_COOKIE_NAME.equals(cookies[nc].getName())) { >> >> _ssoSessionId = cookies[nc].getValue(); >> if (!_ssoSessionId.contains("." + jvmRoute)) { >> _ssoSessionId += "." + jvmRoute; >> >> response.addCookie(new Cookie(_SSO_SESSION_COOKIE_NAME, _ssoSessionId)); >> } >> >> >> } >> >> >> But after this I started getting 401s from even the correct cluster >> member. My guess is addCookie doesnt update the cookie in tomcat's cache >> which is reasonable. >> >> Other thought was to edit tomcat's sso cookie generation code to append >> the >> jvmRoute to the sso cookie. >> >> >> Is there an better way to achieve this in my code base ? >> >> Thanks In Advance, >> Vinod >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org