• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Multiple session objects for multiple login user in the same/ new browser window

 
lavi mendonca
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

As per the project requirement, once a superuser logs into the system, he can then do a search on various users. For every user from the list that he selects, a new browser window opens with details of that selected user and a new session object corresponding to that selected user must be created. Now, if the superuser selects another user from the first browser window, a new browser window (3rd browser window) should be opened with details of that user and a new session object corresponding to that selected user must be created. Also, if the superuser goes back to the 2nd browser (first selected user detail page and clicks on any link of that page/ does some functionality, it should continue with the session of that user. its session should not be corrupted/ overwritten with any other user's session details). Is this possible to achieve using the HttpSession object and if so, how ??

Any help/ pointers/ insights would be greatly appreciated.

Thanks.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by lavi per:

... can then do a search on various users...


What do you mean by various users?
Do you mean, people who are currently logged into the system or people who have accounts?

If the latter, do you mean that when the superuser selects someone from the list, he's actually logged in as that user?
If not, why do you need multiple session objects?
 
lavi mendonca
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Various users means people who have accounts in the system. Initially only the superuser is logged in, but when he selects any user from the search results, it will seem that the selected user has logged into the system. At any point in time, the superuser can select any number of users from the search results and for each of the users selected, a new browser window should open with details corresponding to that user (which is currently happening). The issue is the the last user/ latest user's session is overwriting the previously selected user's session. The project requirement is that individual session data must be maintained in each browser instance/ window corresponding to each user selected by the superuser.

Thanks again.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64959
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Given the way sessions are maintained via cookies, you may have a hard time achieving this. Perhaps by somehow disabling the cookie handling and using pure URL re-writing... But is it really worth all that trouble? (If possible at all?)

In the system I am currently working on, admins (super-users) can choose to proxy log in as any other user, but only one at a time. They must log out to return to being the super-user, at which time they can log in as anyone else again. We avoid the multi-session issue by only allowing a single proxy login at a time.
 
Arun Natarajan
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
* As mentioned by Bear Bibeault, if you are trying to have a distinct HTTPSession for each browser window, it is going to be a complicated and messy implementation if at all possible, and I would avoid it at all costs.

* I assume you have a 'user' object in your session that you populate when a user logs in.
I would not recommend replacing the session info with a different user's details altogether. Even if the super user wants to do things as a regular user, there should be a record of the fact that it was done actually by the superUser acting as the regular user. If your session has a 'user' object to identify the current user, you could add a 'loggedInAs' to identify the user being simulated and use the loggedInAs to determine what functions/ buttons/ links/ screens are available to the user.
If you really want multiple browsers each simulating a different user, then you would change the loggedInAs to be an array or list and pass back and forth the simulated user identifier. Remember that all these browser windows are still using the same HTTPSession.

Also, with your current implementation, after the superUser clicks on the user_1 in the search results, if you are really replacing the session with the user_1's details, then when superUser tries to click on user_2 you should be displaying a 'You are not allowed to do this..'message because to you it would appear as if user_1 is trying to perform something only superUser can do.

Hope this makes sense.
[ June 16, 2008: Message edited by: Arun Natarajan ]
 
lavi mendonca
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you - Ben Souther, Bear Bibeault and Arun Natarajan for your individual responses, but i am still not able to understand your solution.

Since we have been given this requirement, we have to implement it in the cleanest way possible.

Each browser instance should continue to be active for the individual user's session in addition to the superuser's session in the superuser's browser window. Also, if the superuser comes back to his page (search results) or on some other user's page and perform any functionality/ click a link, the session data for that user should remain intact (non-corrupted/ not overwritten) and should display correct details. Using HTTPSession in Java servlets or JSP, how do i achieve this ?

Thanks again.
 
Sri Anand
Ranch Hand
Posts: 392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How many simultaneous users can login is there a limit or should this be implemented very generically ?
 
lavi mendonca
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no limit.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by lavi per:

Since we have been given this requirement, we have to implement it in the cleanest way possible.


Often, the people drawing up the specs don't have enough knowledge about how the technology works, and don't bother to bring someone in who does to consult with during the process. When this happens requirements show up that can't be implemented cleanly (if at all). Browers and JEE servers were not built with the intention of having one user maintain multiple session like this. If a solution like the one that Bear offered won't work for your client then you will probably need to find some method, other than JSPSessions for maintaining state in your app.

Someone might want to pass this back to the client and see if a compromise can be made before you guys find yourselves re-inventing the wheel.

-Ben
 
lavi mendonca
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

We do not have the option of going back. And the requirement of maintaining different sessions for different users (on different browser windows) on the same client machine has to be implemented.

Could someone shed some light on how it can be achieved in JSP/ Java servlets ??

Thanks again.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My first thought is a session scoped user object.
Regular users would have only one bound to session.

Super users would have a map of user objects.
They could be identified with a querystring key.

So, as each request comes in, the app would check to see if the user is a super user. If not use the single user object bound to session. If the user is a super user, get the userId from the querystring and look for the corresponding user object in the session scoped map of user objects. Then, use those credentials for the remainder of the request.

This is just a thought.
I'm sure there will be plenty of issues I didn't think of that will need to be overcome.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic