tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Hamilton" <>
Subject Is there a better way to disable JSESSIONID in the URLs?
Date Tue, 17 Aug 2010 22:01:38 GMT
Using Tomcat 6.0.29, but I think this is version-independent (correct me
if I'm wrong), at least for the 6.0.x versions.


>From what I understand (see for
instance - I also scanned various aspects of the tomcat source code)
there is no way to disable tomcat from putting the JSESSIONID in URLs
automatically with a nice friendly global switch/property.  The only way
I've seen how to do this, as suggested on the site I referenced, is to
put into place a servlet filter.


I'd like to know if I'm missing anything - is there a better way to do


We have an app whose security is a concern for our customers, and
JSESSIONIDs appearing in the URLs freak them out (especially when they
demonstrate that you can get a URL from the app, email it to someone
else, and have that person magically bypass authentication and assume
the role of the other user - of course as long as the session is still


We are comfortable saying that in order to use our application you need
to have cookies enabled, so I'm making the assumption that if we disable
the feature of putting JSESSIONID into the URLs, either through a nice
global switch or else a servlet filter, cookie-based session
setting/tracking will still function just as we expect it.


Finally, anyone know why this isn't already in the servlet spec?  Seems
like with more and more concern over web application security that this
would be something the spec should address?




The information contained in this e-mail message is intended only for the personal 
and confidential use of the recipient(s) named above. This message is privileged 
and confidential. If the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are hereby notified 
that you have received this document in error and that any review, dissemination, 
distribution, or copying of this message is strictly prohibited.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message