Be Truthful to yourself!
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Originally posted by Peter den Haan:
Quite simply, you can't. In an older version of the API you could use HttpSessionContext.getSession(String).invalidate(), but that is deprecated and getSession will just return null.
When coding an alternative, you need to take very good care of your clean-up - specifically, if a user's browser crashes (s)he should be able to log back in using a new browser instance.
After a successful login, you could store the current session's ID (Session.getId()) against the user. For every protected page, you execute a bit of code that compares the user's stored session ID against the current session; if they are different, zap the session and present a login screen. If you are using a Servlet 2.3 container you can use a filter to do this.
Storing the session against the user can be done in a database, but if you're not using a distributed container you may just as well use an application-scoped Collections.synchronizedMap(new HashMap()) mapping a User object to its associated session ID.
- Peter
[This message has been edited by Peter den Haan (edited October 04, 2001).]
Be Truthful to yourself!
You can't. However, in the set-up I proposed the previous session will zap itself as soon as a request comes in for it, which is the next best thing. It's "passive" rather than "active" invalidation, but from the user's point of view it doesn't make a difference: when a second session is established, the first one is rendered unusable.Originally posted by deepak bansal:
I have to zap the previous session of the same user [...]
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Be Truthful to yourself!
Be Truthful to yourself!
Be Truthful to yourself!
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Be Truthful to yourself!