views:

354

answers:

2

I am having ASP .Net application which is running perfectly in IE 7.0 but as due to session sharing in IE 8.0 (also in case of new window), application is giving unexpected behavior as session can be modified by other window.

Some quick facts

I know the -NoCache option and open New Session file menu item of IE 8

I just wanted to know that is there any option to disable this session sharing behavior in new window through ASP .Net code (by getting the browser) or any other solution

I also wanted to have your suggestions for future web application development, what we need to take care to avoid session sharing issue

+1  A: 

Session sharing has always been there is not unique to Internet Explorer 8. New tabs, Ctrl-N in any browser (IE5,6,7 FF1,2,3 OP6,7,8,9,10 etc) shares the session data of the global process. It just received a fancy name because now tabs can have multiple processes on the computer (not new either), but will still "share" the sessions. And thats' kinda "new".

It is good that you're aware of this, but it's not so good if you're trying to take this "experience" or "feature" away from the user. If you want that, I'd check into JScript/JavaScript solutions instead and issue a warning when a user tries to open several sessions, but I doubt you'd get a good "prohibit sharing sessions across windows" solution. Even notable banks have already given up on this (they never liked this session sharing thing)

From a design perspective: on the server side, it is rather simple. Just always assume that the session is changed. This can, for instance, mean that on one screen, the user is not logged in, on another he is. That's ok. If he refreshes or goes to another page, you'll show him the correct view: logged in user for the same page.

Just make sure that you check for invalidated data as the result of a changed session in another window (i.e., request). But that's a general advice: be liberal in what you accept, but make sure you validate any input.

EDIT: On extra sessions: just treat them like that. It has always been possible that users open up more then one session for the same user (two different browsers). Just as it has always been possible to change a session through another tab, window etc of the same browser.


On the "solving" side: Configure the session as cookieless. This places the session in the URL query params. Any old window not having the SESSIONID in the URL will not be considered part of the session. However, a warning is in place: this approach eventually causes more trouble then it solves (i.e., now you have to worry about with and without session requests from same user, same browser, same ip and it's still possible to "copy" a session by copying the URL or tab).

Abel
Just make sure that you check for invalidated data as the result of a changed session in another window (i.e., request). But that's a general advice: be liberal in what you accept, but make sure you validate any input. Can You explain it by giving good example? By validating you mean if session is changed in another window we can restrict the operation...
Harryboy
I have a hard time thinking of an example where it can really mess up (provided what you say: you validate the input, and what I say, you always assume change). Are you looking of a situation where it can go wrong, or are you looking for a fix for a currently wrong situation?
Abel
A: 

Moving some of your information from Session to ViewState may help you solve the issues you are having.

ck
session is server side, viewstate is client side. Good advice, but be careful with this when your session contains sensitive data.
Abel
first i can not change my existing code as it means heavy cost to me, second if i am designing a new application in that scenario also if there is any heavy object i can not store it in viewstate
Harryboy