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