Creating / Handling multiple sessions

Question

How can I create multiple sessions with Servlets/JSP?
The requirement is this:
An admin-type user logs into my application. There, he can see a list of normal (non-admin) users, and should be able to log into those users accounts. Therefore, it is necessary to start a new session as this user, while the he should still be able to be logged into his admin account (and log into more users accounts, if need be). So, the admin session must remain valid, and for each login into a user account, a new session must be created.
I understand that this is not possible using the standard cookie-based approach, so I turned them off for the respective context in Tomcat and encoded all URLs using <c:url ...>. Still, I don't know how to start a new session, there seems to be no method to do this. When there is an active session, getSession(false) returns it, that's all I get. So how do I create a new session with a new session id?
While trying to figure this out, I also noticed some odd behavior in Tomcat (Version 6, though this might apply to other Tomcat Versions or even other web containers. If no session is yet active (like, on the Login page of the application), or the active session is being invalidated (as after logout), a new session is created every time one of those pages is accessed. This also happens if no session id is given at all in the URL (and, probably, if an expired session id is submitted, I didn't try this one yet).
This is not good, simply speaking. This way, the web container will quickly get swamped with ghost sessions that were, on my part, never created, and never used; still, they hang around until they expire, of course.
Any ideas? :)

Answer 1

BalusC wrote:
Tyrathect wrote:
Bad approach? Could you elaborate please? :)It is just plain cumbersome and coding is impossible without horrible hacks.Hm, why cumbersome? The only difference between your approach and mine is that I would use two seperate sessions, as if the user had logged in using his username and password, while you would use one session for both.
As for coding, I see no need for hacks. The admin is supposed to be able to create users, enter/change some contact data and do some settings for the users accounts, and log in as that user (without having to ask him for his login credentials) for support cases etc. Where is the need for hacks here? Except maybe if there is no way to create a session from another session...
but it wouldn't allow for an admin to look into more than one user account at once (right?) which is somewhat a requirement.So you want to impersonate more than one user simultaneously? What's the benefit of this? If you want to switch between users, just go back to the admin panel and pick another user.Yes, or rather, support staff will want to do this.
This is a common scenario in the company I work for, where 3 support people serve about 1000 active customers (of another, PHP-based project). Customer calls, a supporter will use the admin account to log in to his account and have the problem explained. If the solving takes longer, he will tell the customer that he will look into it and call back when it's sorted out. Now while he is working on this, the next customer calls, so the supporter will use the admin account again to log in this account, also, to have the problem explained etc. If the second problem is solved quickly, he will then just log out of the second customers user session and simply continue working on the first customers problem which is still active in another browser window.
Now, if the support people can have only one user session open at a time, they will have to close the first customers user session they were working in (probably having to save some work only halfway done) when the second customer calls, log in to that second customers account, help him, log out of the account to go back to the admin panel, log back into the first customer account, resume work there.
Long story short, while the first approach enables them to do small tasks on the side while working on a bigger problem, this is not possible in the second approach.
Still, any idea about the rogue sessions when I wrote about in the last paragraph?I don't understand your doubt. Every request should take place in a session. If it isn't there or if it is invalidated/expired, then the appserver will create one. I don't see how that is a problem.Ok, if this is normal behavior, then no problem. I just got suspicios when sessions kept appearing while I was not creating any myself.