tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Session management issue with Tomcat
Date Tue, 20 Sep 2011 17:20:02 GMT
Hash: SHA1


On 9/18/2011 11:05 AM, Martin O'Shea wrote:
> I have a situation where I'm using Tomcat 6.0.26 but the logging in
> / out of the application is not authenticated via Tomcat's:
> action='<%= response.encodeURL("j_security_check") %>' >
> method.

You mean to say that you are using your own authentication mechanism,

> The current system allows cookies to store userids which are used
> to show recent lists on the homepage of the application. So for a
> session, a user's userid can be read from the cookie and used to
> retrieve their details from the database and store them in the
> session, and render the hompage with its personalised recent list.

So, any remote user can provide a forged cookie to read anyone's
"recent list" if they want? You might want to encrypt those cookies.

> The user's id can also then be placed in the login username box
> with the password stored in the session.

So, you use an untrusted user id coming from a remote cookie to
populate the user's username and password on a login page? Sounds like
that's a problem.

> But, in a single browser session, if the first user logs out, and
> another user logs in, the cookie is re-written with the new user's
> userid. But, because this is all in one browser session, use of the
> browser's back button allows the new user to access the profile
> details of the first user if the first user visited the page before
> logging off.

So, what you are saying is that the design of the web browser allows a
second user to observe what the first user did by looking at the
history and/or cache? There's not a lot you can do about that. You can
send "no-cache" response headers to the browser, etc. but there's
always a chance that the browser doesn't respect them, etc. and the
history can be viewed.

I'm not sure there's a way around that. Even if you use javascript to
kill the window/tab, many browsers have a "re-open closed window/tab"
that will resurrect the window/tab with the history in-tact, so you
haven't bought anything there.

I guess this is why you should be careful what you do from as public
terminal, eh?

> No secure data is held in the system.

That's good, given the shaky security you've described here.

> Can anyone suggest a way to change this? I am no expert on session 
> management.

It's the browser that is the problem, not your session management. I
think you need to instruct your users to completely exit the browser
after they use your site if they value their privacy.

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message