Session problem: jsessionid Cookie comes back with double quotes

[tb_google]

Hi,

I have a problem with some browser clients (UMTS phones, to be exact):
Tomcat sessions are not recognized in subsequent requests. It happens
with Tomcat 5.0.27 and also with Tomcat 5.5.4.

I found that request.getRequestedSessionId() returns
"F432814F1B91E827C17D6F1BF6D1A724" - including the double quotes!! On
other browsers and phones, the quotes are not included.

isRequestedSessionIdFromCookie() returns true, but
isRequestedSessionIdValid() returns false, which seems to cause the
problem. On other browsers isRequestedSessionIdValid() returns true.

So I think that the problematic phones do not send the cookie header in
the way Tomcat expects it. And then the wrong jsessionid cookie cannot
be assigned to a session. Unfortunately it does not help to use
;jsessionid=... in the URL as the cookie value has precedence.

Is there any way to fix this?
Maybe to filter the requests and modify the headers Tomcat sees?
Or to change the implementation of reading Cookies from the headers?
Or to change the implementation of finding a session according to the
cookie value?

Your help is greatly appreciated!

Thomas

 

[John C. Bollinger]

Hi,

I have a problem with some browser clients (UMTS phones, to be exact):
Tomcat sessions are not recognized in subsequent requests. It happens
with Tomcat 5.0.27 and also with Tomcat 5.5.4.

I found that request.getRequestedSessionId() returns
"F432814F1B91E827C17D6F1BF6D1A724" - including the double quotes!! On
other browsers and phones, the quotes are not included.

isRequestedSessionIdFromCookie() returns true, but
isRequestedSessionIdValid() returns false, which seems to cause the
problem. On other browsers isRequestedSessionIdValid() returns true.

So I think that the problematic phones do not send the cookie header in
the way Tomcat expects it. And then the wrong jsessionid cookie cannot
be assigned to a session. Unfortunately it does not help to use
;jsessionid=... in the URL as the cookie value has precedence.

Is there any way to fix this?

The best long-term solution is to figure out which software is buggy and
have the manufacturer fix it. If the bug is on the client side (more
likely) then I'd strongly consider leaving it at that, and simply
documenting somewhere that certain clients are known to be buggy in this
way and don't work with the software (or with a lot of other software, I
would expect). If the bug is on the server side (less likely) then it
makes sense to implement a workaround until the server is fixed.

Maybe to filter the requests and modify the headers Tomcat sees?

A servlet filter might be able to handle this, but it depends on the
details of how and when Tomcat binds requests to sessions. You could
certainly set up an external filter in front of Tomcat to do the job.

Or to change the implementation of reading Cookies from the headers?
Or to change the implementation of finding a session according to the
cookie value?

It is probably not worth your time or effort to seek a solution by
mucking in Tomcat's internals.


John Bollinger
(e-mail address removed)

 

[Thomas]

Well, I tried that now. But request.getRequestedSessionId() is already
set to the wrong value when this method of the Servlet Filter is
called: doFilter(ServletRequest request, ServletResponse response,
FilterChain chain)

So I can change the cookie (cookie.setValue(...)), but it seems that
the Tomcat looks uses the JSESSIONID cookie before my filter is called.


Is there any other such kind of configuration option to grab and modify
the JSESSIONID cookie before Tomcat uses it? Or could I maybe even
replace the class used for session management and override the method
for looking up the sessions?

Yes, there is! I found it and implemented this solution: A class
extending org.apache.catalina.session.StandardManager and overriding
the method public Session findSession(String id) throws IOException -
simply removing quotation marks, if any! Seems to work fine.
Thanks for putting me on the right trail!

Thomas