Problem with HttpServletRequest.getSession() in Firefox

[nandipinto]

Hi all,

I have a strange problem with HttpServletRequest.getSession() in Mozilla Firefox. I have a java class that extends org.springframework.web.servlet.mvc.AbstractContro ller. Inside the handleRequestInternal(HttpServletRequest request,
HttpServletResponse response) method, I tried to get session Id from the request object (request.getSession().getId() or request.getSession(true).getId()).

The strange thing is, even if I open a new instance of Firefox (not using File->new Window or File -> New Tab) I always get the same session Id, which doesnot happen in IE. And the same problem also happens if I use request.getSession().setAtribute() method.

Could anyone help me on this, please?


Best rgds,


nandipinto

[Colin Yates]

The strange thing is, even if I open a new instance of Firefox (not using File->new Window or File -> New Tab) I always get the same session Id, which doesnot happen in IE. And the same problem also happens if I use request.getSession().setAtribute() method.
Yep; Firefox basically opens a new window *even if you start the same executable*. IE doesn't.

Haven't told you anything you didn't know; your diagnostic was also the explanation :)

[Cowboy Bob]

I'd argue that FireFox has the correct behaviour. If I middle click a link on a page to put the contents of the link into a new tab, I don't expect to have my new tab be placed in a new session.

You'll also want to check IEs behaviour on older versions (5.5 and below). I definitely remember it always having the same session ID unless you closed down all your open IE windows (and Windows Explorer as well since it's effectively the same program). This was on Windows 2000 - I've never used Windows XP.

[Colin Yates]

I'd argue that FireFox has the correct behaviour. If I middle click a link on a page to put the contents of the link into a new tab, I don't expect to have my new tab be placed in a new session.

No, for sure. However, clicking on the firefox icon in widows arguably *should* start a new instance of the browser....

[Cowboy Bob]

No, for sure. However, clicking on the firefox icon in widows arguably *should* start a new instance of the browser....

Only if there are no other FireFox windows open. After all, that is (or at least was) the default behaviour of IE so they've probably just modelled the behaviour on that.

I fail to see how starting a new FireFox instance if there are no other FireFox windows open could result in the same session ID since the session ID is stored in a session cookie and this shouldn't be persisted.

I can't test this though since I don't have a Windows machine available. However, it's certainly how FireFox behaves on my Linux machine.

[Colin Yates]

Only if there are no other FireFox windows open. After all, that is (or at least was) the default behaviour of IE so they've probably just modelled the behaviour on that.

Was that the default behaviour of IE? Clicking the IE icon now starts a new instance, hence new sessions. Wonder when they changed it?


I fail to see how starting a new FireFox instance if there are no other FireFox windows open could result in the same session ID since the session ID is stored in a session cookie and this shouldn't be persisted.

Nobody suggested it should :) What I suggested was that clicking on the firefox icon should *always* start a new instance, not open a new window.

OK; "opening new window" is ambiguous; I mean open a new window on the existing instance.

[Cowboy Bob]

Was that the default behaviour of IE? Clicking the IE icon now starts a new instance, hence new sessions. Wonder when they changed it?


Last time I used IE it was IE 5.5 on Windows 2000. I suspect the change happened with IE 6/Windows XP but I've never used either of those.

Back in the day (around 2000/2001) I was involved in working on a multiplayer version of Mahjong (the proper game, not the solitaire version). In order to test the game on IE (ie have more than one player) we needed to use different machines since IE refused to give different session IDs regardless of how it was started. Either that or use one instance of Mozilla and one instance of IE.

Anyone expecting a new session with a new instance should definitely test on older versions since they're still very much "in the wild".

[Colin Yates]

Anyone expecting a new session with a new instance should definitely test on older versions since they're still very much "in the wild".
Good call. I am currently working somewhere where they still support NT4 :(

[manifoldronin]

Sometimes, as a Web user and a developer, I do wish Firefox could at least give an option to start a new session when a new instance is started (i.e. as yatesco said when I click on the Firefox icon). Of course spawning a new tab or new window from an existing instance should share the same session without question.

One typical example would be that I have two accounts with my broker, and from time to time I need to consolidate the record between the two. So naturally I would like to log into both at the same time.

[nandipinto]

Hi all,

Thanks for your replies. However, if that's the case, could anyone please tell me the best practice to manage app. session? (ofcourse, it should be cross-browser capable). Since what I do most of the time is to use HttpServletRequest.getSession().setAttribute(..,.. ).

Best rgds,

nandipinto.
--new to linux, new to firefox--

[Cowboy Bob]

To be honest, if your application breaks because someone has opened a link in a new tab with the same session ID then there is most likely something wrong with your design somewhere. An application shouldn't care what window it's in as long as it has a valid session ID - which it does according to your original post.

What exactly is the problem you're having, other than having the same session ID? I suspect that there's another issue here rather than the symptoms you've described.

[nandipinto]

Hi Bob,

I was trying to develop a simple shopping cart app app that requires the user to logon before he can make an order. Here is how I design the app:

- a User object
- an Order object
- a DAO
- a UserService that will be used by the LoginController to validate the identity of the user.
- an ShoppingCartService
- a LoginController
- a ShoppingCartController

After successful login attempt, the current user info will be bound to the session, and ofcourse is allowed to place an order.

Here is how I bind an instance of User object to the session:

request.getSession().setAttribute("currentUser", user) - I also tried to use request.getSession(true).setAttribute("currentUser", user)

What I've done to test the app was to open two Firefox and tried to logon to the app using two different user accounts.
First user makes selection of some articles to be placed into the shopping cart, the ShoppingCartController binds the list of articles to the session using the same mechanism above.
The second user alsow do the same thing, but with different articles selection.
Before the user can submit his article selection, my app shows a confirmation page which shows the selected articles.
The strange thing is, the second user (the one that uses the other Firefox instance) gets the same list of articles as first user.
This, however does not happen with IE.

am I doing it the wrong way?


best rgds,


nandipinto

[Cowboy Bob]

I wouldn't say you were doing it the wrong way as such. However, you're implying that the second user logs in and gets the first users cart. What you should do to make this safe is to check if the user is already logged in (and if so either give them their cart back or remove the user and cart object) because it sounds like what you have is a case where the server should recognise the first user until they log out (the session won't expire until you hit the session timeout set in your web.xml).

You can also automatically log them out (and destroy the session with HttpSession.invalidate()) when they have finished confirming the order.

Remember, this will (almost) never affect real users, only your testing, so as long as you make sure that nothing breaks for a user and make sure that they can never order something twice by accident, then everything should be OK.

[amitabhprasad]

I wouldn't say you were doing it the wrong way as such. However, you're implying that the second user logs in and gets the first users cart. What you should do to make this safe is to check if the user is already logged in (and if so either give them their cart back or remove the user and cart object) because it sounds like what you have is a case where the server should recognise the first user until they log out (the session won't expire until you hit the session timeout set in your web.xml).

You can also automatically log them out (and destroy the session with HttpSession.invalidate()) when they have finished confirming the order.

Remember, this will (almost) never affect real users, only your testing, so as long as you make sure that nothing breaks for a user and make sure that they can never order something twice by accident, then everything should be OK.

I disagree with above statement and the solution, web is no longer offer just some browse and buy some simple stuff.Like currently I am working on web version of desktop configuration application where application involves complex configuration and opening multiple sessions comparing two solutions and so forth, using same session id/object is looking at this complex problem and keeping a closed eye.
Sorry if my statement hurts, but this blocker and we are looking at redesigning the entire app.

[amitabhprasad]

Can some body give any insight of a possible solution ,will really appreciate this thanks.

[nate]

amitabhprasad:

This is an old thread that doesn't seem to have much to do with your problem.

If I were you, I would continue to search for the answers to your questions in the forums and start a new thread if you cannot find what you need elsewhere.

Cheers.
nate