Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of appy74@dsl.pipex.com
 designates 212.74.114.37 as permitted sender)
From: "Martin O'Shea" <appy74@dsl.pipex.com>
To: "'Tomcat Users List'" <users@tomcat.apache.org>
References: <002d01cc7614$5c170de0$144529a0$@dsl.pipex.com>
 <4E78CB42.7070602@christopherschultz.net>
 <E461967C-0608-44A7-98CC-641084DCCDBC@umich.edu>
In-Reply-To: <E461967C-0608-44A7-98CC-641084DCCDBC@umich.edu>
Subject: RE: Session management issue with Tomcat
Date: Thu, 22 Sep 2011 14:03:15 +0100
Message-ID: <002f01cc7927$fdcae600$f960b200$@dsl.pipex.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQI3yh9vt3dMDkgHkqRqFgq98HSkMALB8FHQAmNn+pWUWY+9UA==
Content-Language: en-gb

Shanti

I was thinking that this was the problem and at the moment I have been
trying to force the pages to reload from the server by using a filter to
prevent browser caching as follows:

try {
            HttpServletResponse hsr = (HttpServletResponse) response; 
            hsr.setHeader("Cache-Control", "no-cache, no-store,
must-revalidate"); // HTTP 1.1. 
            hsr.setHeader("Pragma", "no-cache"); // HTTP 1.0. 
            hsr.setDateHeader("Expires", 0); // Proxies. 
            chain.doFilter(request, response);
        } catch (Throwable t) {
...
}

But the results are imperfect.

Is this the sort of thing you mean?

http://www.koelnerwasser.de/?p=11

Or can you tell me what to do if I am wrong?

Thanks

Martin O'Shea.

 
-----Original Message-----
From: Shanti Suresh [mailto:shanti@umich.edu] 
Sent: 22 Sep 2011 13 57
To: Tomcat Users List
Subject: Re: Session management issue with Tomcat

Hi Martin,

You will have to expire/invalidate the session in the code upon user logout.
This way when the cookie comes in, there is no corresponding session-ID and
the system will create a new session.  Are you doing that already?  Does
that help?

             -Shanti

On Sep 20, 2011, at 1:20 PM, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin,
> 
> 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, 
> right?
> 
>> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk54y0IACgkQ9CaO5/Lv0PAmLwCfRB69FXn1XUhPbMHQKD/Q/xAd
> QssAoJMKQk4xudqoGJlf0vkhdLZCkFkp
> =rYmn
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
> 
> !DSPAM:4e78cb6c11371347337680!
> 
> 
> 

--
Shanti Suresh
App Systems Analyst Lead
Web Services, LSA Development
University of Michigan
Office: 734-763-4807
shanti@umich.edu
http://lsa.umich.edu/cms


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org