aspose file tools*
The moose likes Servlets and the fly likes Killing The Session ??? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Killing The Session ???" Watch "Killing The Session ???" New topic
Author

Killing The Session ???

deepak bansal
Ranch Hand

Joined: Feb 25, 2001
Posts: 33
Hi All,
I am facing a problem regarding maintaining the session ..
My Requirement is -->
Single Login- If the User Logs in from a different Machine or different browser, the previous session(for the same user) should be deleted and a new session should be created for the User.
How do i maintain it ???.How do i know that user has previously logined.One option is to have a flag in the data base .But that wont solve the purpose .I have to kill the previous session...We r working on weblogic6.0
Pl reply ASAP..
Thanks
Deepak
------------------
Be Truthful to yourself!


Be Truthful to yourself!
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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).]
deepak bansal
Ranch Hand

Joined: Feb 25, 2001
Posts: 33
Thanks Peter,
You wrote..
"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.
"
I have to zap the previous session of the same user and have to create a new one NOT have to presant the login screen.How can i use the Servlet 2.3 container's filter.I dont want to use HashMap.(That is last resort)
Thanks for the support.
I am waiting for your reply.
Deepak

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!
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by deepak bansal:
I have to zap the previous session of the same user [...]
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.
- Peter

[This message has been edited by Peter den Haan (edited October 04, 2001).]
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Ok, I take that back. You can. Create an /invalidate servlet and use java.net.URL to construct a request for "http://localhost/invalidate;jsessionid=FIRSTSESSIONID". This request then executes under the first session and is able to invalidate it.
But do you really want to go there?
- Peter
deepak bansal
Ranch Hand

Joined: Feb 25, 2001
Posts: 33
I Propose the Following solution If you find any loophole in this the apprise me -->
I am storing the session object against the key (userid) in the HashMap . Now if the same user logins from the differnt machine then i will check for that userid whether the session object is there or not .If it is there in the HashMap then i will invalidate it and will create a new session object .
What do you think ..???
Waiting for your reply
Thanks
Deepak
deepak bansal
Ranch Hand

Joined: Feb 25, 2001
Posts: 33
Hi Peter,
In reference to your last reply pl tell that how do i construct the request Using the java.net.URL.
Thanks
Waiting for your reply
Deepak
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
deepak,
in your new strategy, what if a session automatically times out? is it then automatically deleted from the hasmap? and if so, how are you triggering this?
-miftah
[This message has been edited by Miftah Khan (edited October 04, 2001).]
deepak bansal
Ranch Hand

Joined: Feb 25, 2001
Posts: 33
Hi Mitafh,
That you can do by using HttpSessionBindingEvent interface. What ever the object you r storing in the session should implement the above interface and define the
valueUnbound(HttpSessionBindingEvent event) method. write the code to clear the HashMap in this method.
Thanks
Deepak
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
There are a few problems with this method, which may or may not be important to you.
  • The fact that every other session will be directly accessible may represent a security risk; this is exactly the reason why Sun deprecated HttpSessionContext. You can address this by storing not a raw HashMap, but rather an object which contains a private HashMap and performs the duplicate user check for you.
  • This method cannot be adapted to work in a distributed container.

  • - Peter
deepak bansal
Ranch Hand

Joined: Feb 25, 2001
Posts: 33
Hi peter ,
You r correct that above method has the problems mentioned by you. what do you say about the method mentioned by you by creating the request by the previous session id and submitting it to invalidate server . Wont this be problematic in multi container environment ?.. If not the send me guidline to proceed further.
Thanks
Deepak
 
 
subject: Killing The Session ???