Often you want to prevent the same user account being used simultaneously in different sessions (business license restrictions being one reason, complex technical synchronisation problems being another)। There are two typical strategies to prevent थिस :-
#1. Prevent any new sessions while a session with the same user account exists.
#2. Allow a new session, but disconnect any previous sessions if they exists.
Imho, I think #1 can be very problematic for the user. If the user faces a system crash during his session, his subsequent attempts to login after recovery will be thwarted. Until his previous session times out, he will be left twiddling his thumbs. Using cookies to maintain the session information would be a good idea here. If you are supporting auto-login, then you are already doing something like this. A session id stored in the cookie, would be enough clue to server to reconnect to the same session. You need to ensure however, that the user does a proper 'logout' - even going to the extent of hooking your 'logout' into the body unload event if the user chooses to shut the browser window, without clicking on your 'logout' link.
Now what happens when a user logs into your site, shuts his browser, deletes his cookies and tries to login again, before his session times out ?? Let him suffer, i say ! :)
#2 is much easier to implement. All you need to do is maintain a Map of user accounts with their sessions in application scope. Add a listener for session timeouts, to remove these entries from the map when the session times out. When a new session if being created, simply look up the map for previous sessions by the user and invalidate them if present and also remove them from the map.
I'd like to hear your comments on how you achieved similar requirements।
Cheers
Aldrin
5 comments:
hi there,
I second strategy #2. The problem with this is someone else(if he has the user's credentials) close the actual user's session (say, for creating problems for the original user)
But you should not easily dismiss strategy #1 either. One could provide an admin user with ways to delete a certain user's session.
BR,
~A
What about same user session but multiple browser windows, ex: login the user from Browser windowA, then after some logon the same user from windowB. how shall session be managed
anjanbacchu,
True - an admin could invalidate certain sessions. The only problem I see is that it would be a manual process. In fact, this was how it was done on one project that I was acquainted with.
Cheers,
Aldrin
maxblacks,
The same principle holds here too with multiple browser windows. The server doesn't care, it just see it as two different login attempts.
Cheers,
Aldrin
I actually used a poor form of #1 on one project, where we didn't use cookies, but maintained a flag in the db against each user. So if the flag was true and another login was attempted, it was prevented. We had a session listener resetting those flags on expiry of a session, but the problem here was that if a user did not explicitly log off (happens almost all the time), or his machine crashes, then he was locked out for the session timeout period. The admin had a facility to reset those flags to unlock his account...
-Luanne
Post a Comment