tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Cookie-less session tracking - whats are the downsides
Date Thu, 17 Apr 2008 13:38:38 GMT
Hash: SHA1


mfs wrote:
| I would want to know the downsides to using cookie-less sessions ? I
want to
| give my client the freedom to disable cookies on the browser if he chooses
| to, but i would want to know the implications to that ?

I disagree with nearly everything this guy has to say (laziness is no
excuse and it's no less risky than using cookies), except for the part
about the search engine problems (which shouldn't be understated). The
author provides a workaround for that, though. Unfortunately, that
solution generates /lots/ of sessions unless your code handles it properly.

Frankly, you should be avoiding sessions without authentication in the
first place, search engines should never authenticate, and therefore
your application should never generate a session for a search engine,
and the problem is gone. There are certainly reasons to create sessions
for non-authenticated users, but this is one argument against doing that.

| Some say, exposing your sessionId in the url exposes it to hackers who can
| spoof the IP (as of the victim) and provide the jsessionId (in the
url) and
| can gain control of the victim's session, but if u are using ssl, that
| shouldnt be an issue.

...and this is just as easy with cookies. They are no less susceptible
to this type of attack. The only difference is that URLs (including the
jsessionid) are often logged on proxies and web servers, while cookies
are almost never logged.

SSL fixes everything but the logging, which shouldn't be a problem on
properly secured systems.

| Would someone comment on the real hazards/bottlenecks to the cookie-less
| approach.

The only runtime bottleneck is the time required to add
";jsessionid=123456789" to your outgoing URLs, which is to say "pretty
much nothing". The engineering bottleneck is that you have to run all
your URLs through HttpServletRequest.encodeURL or
HttpServletRequest.encodeRedirectURL (which you should have been doing
all along, right?).

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message