On 22/09/2011 19:49, Martin O'Shea wrote: > To answer your questions: > > Is there a reason this data is in a custom cookie, rather than the > session, via setAttribute()? > > The cookie is dedicated and meant to be persistent. The idea is that a user > is recognised by the system upon returning to the website after having been > away for some time. Hence, the userid is stored in the cookie, so that when > the user returns to the homepage, the homepage can read the cookie, and > present that user's recent list on the page. > > What is the expiry time of the custom cookie? > > The cookie is set for a year. > > How exactly are you invalidating this other cookie, when you > invalidate the session? > > I assume you mean Tomcat's session and not the browser's sessions. The > Tomcat sessions are not being invalidated at the moment. > > The underlying principle here is that if multiple users use the same PC, and > maybe even the same session in a browser, a single cookie is used to store a > userid. Various system pages have a login facility and if invoked, the > cookie is rewritten with the current user's id. But this is where the Back > button issue occurs so it may be that session invalidation solve my > problem.
I don't understand... How can a new user log in, if you're not logging out? If you're using FORM auth, then you need a logout mechanism to do that, and a logout mechanism requires you to invalidate the http session in Tomcat. p
signature.asc
Description: OpenPGP digital signature
