Is there a reason this data is in a custom cookie, rather than the
session, via setAttribute()?
What is the expiry time of the custom cookie?
How exactly are you invalidating this other cookie, when you
invalidate the session?
p
On 22 Sep 2011, at 15:08, "Martin O'Shea" <app...@dsl.pipex.com> wrote:
> OK. This is what the contents of a typical cookie on the system look like:
>
> 978937_19082010_1282218386857
> localhost/
> 1024
> 2913476352
> 30544688
> 1374261013
> 30177561
> *
>
> Where userid is 978937_19082010_1282218386857 matching the key of the user
> table in the database.
>
> The cookie is not encrypted.
>
> Code in the system to retrieve the cookie is:
>
> // Gets the value of a cookie.
> public static String getCookieValue(Cookie[] cookies, String cookieName)
> {
> String cookieValue = ("");
> Cookie cookie;
> boolean found = false;
> if (cookies != null) {
> for (int i = 0; i < cookies.length; i++) {
> cookie = cookies[i];
> if (cookieName.equals(cookie.getName())) {
> cookieValue = cookie.getValue();
> found = true;
> break;
> }
> if (found) {
> return cookieValue;
> }
> }
> }
> return cookieValue;
> }
>
> The cookieName parameter here is the name of the cookie which is myAppUser
>
> This all seems to work fine.
>
> -----Original Message-----
> From: Martin O'Shea [mailto:app...@dsl.pipex.com]
> Sent: 22 Sep 2011 14 03
> To: 'Tomcat Users List'
> Subject: RE: Session management issue with Tomcat
>
> 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:sha...@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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>> !DSPAM:4e78cb6c11371347337680!
>>
>>
>>
>
> --
> Shanti Suresh
> App Systems Analyst Lead
> Web Services, LSA Development
> University of Michigan
> Office: 734-763-4807
> sha...@umich.edu
> http://lsa.umich.edu/cms
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
