Peter Claesson (EUS) wrote: > Very true. Not having access to the actual code is very limiting. I took your > suggestion and started looking in to the session tracking. My application uses > the htpSession APIs. There is no URL rewriting taking place in my code. > > The part of the application where I loose the session tracking is right after I > performed a page assertion. What this means is that the client browser application > runs a number of javascript to read through the contents displayed in their main >browsing > window. The information is serialized into a string, which is sent to the call >center agent > application. Once there, another set of javascripts takes the serialized string and >builds up > the corresponding web page including contents that the user view and have entered. > The page is viewed using the cc agent cookie. > In order foe the call center agent to view the exact same information, the client >also > sent the JSESSIONID for the client cookie. The code checks if the cookie needs to > be applied, and if so, sets the current cc agent cookie = customer cookie. The page > is then reloaded. > > I assume the that it is here that I loose the session. If the sessionID is kept in >the > cookie and the local cookie is set to the remote cookie, that mean the sessionID > is changed. Hence, once the poller comes around, the poller GET is then > associated with a different session (=new object instantiation). Is this reasoning >correct?
Sorry, but it's hard to visualize all the JavaScript tricks and cookies flyng around ;-) But, it sounds like you may be on the right track. Basically, for session tracking to work, each request to the server must contain the same session ID. If cookie-based tracking is used, this means a JSESSIONID cookie must be present in each request. It sounds like in your application, sometimes it may be missing. This will defintely cause problems. > If this is the case, what is my workaround. The only thing I can think of is to >delay the > poller until the page assertion is completed and the old local cookie information is >written > back to the cookie. Other ideas... If that means every request contains a valid JSESSIONID cookie, yes it would likely solve the problem. Another approach is to use URL rewriting, i.e. make sure all URLs contain ";jsessionid=xxx" by passing them through the response.encodeURL() method. Note that this method does not add the session ID info if the container determines that cookie-based tracking can be used. For some containers, you can disable cookie-based tracking to force it to always add the session ID. If you haven't prepared for URL rwriting from the start, you may have a lot of work ahead of you if you want to add it now. *Every* URL in the application must be encoded (links, form action attributes, URLs in JavaScript, etc.). Some containers also support session tracking based on SSL sessions. This requires the client to have a client certificate, though. So, making sure all requests contain a JSESSIONID cookie is probably the least painful solution. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
