Preventing shared session variables

[Former Member]

A user opens an IE window on a computer and logs into MII as "operator". The initial screen requires the user to enter in information that is used throughout the MII application (ie, employee number, work center, date, and shift). This information gets created as session variables in MII and are referenced on many of the other MII application screens. Then, the same user opens a new IE window (not tab) and logs into the same MII server again as "operator". At the initial screen for the user enters a different work center and shift.

For some period of time (and most times always), the session variables are unique between the two browser sessions. However, frequently, the first session shows the second session's session variable values and the second session shows the first session's session variables. Or, sometimes, both IE sessions have the same session variables.

From what I was able to research, by design, separate IE windows should produce separate iexplore.exe processes and handle separate session ids and variables. Tabs within a single IE session should share the ids and variables. However, IE7 and below had some problems enforcing this. IE8 has a "nomerge" option (iexplore.exe -nomerge) that is suppose to force each browser window and each browser tab to control separate session ids. In a rather controlled environment, we installed IE8 and used the nomerge option but are still experiencing the issue.

I also realize that IE is only controlling the client session space (for cookies, etc).

Is it possible for a single person to login to MII as the same "generic" user multiple times using separate IE windows but maintain separate session variables for each browser window - technically speaking, not due to any licensing issues?

[Former Member · Accepted solution]

Hi Ryan,

I've seen this situation in my tests here when the 2nd window of IE is spawned from the 1st one where the operator is already logged in (windows/tabs being opened from a link or request). If the operator starts the second window of IE from the taskbar menu and logs in with a different username, the session variables do not mingle. However, if the operator uses the same username/password to log in the 2nd time form the same machine, the application server "thinks" it is the same operator and does not create a new server session, reusing the 1st one and mingling the variables.

On a single server node you should be able to accurately monitor the Active Session list from the Menu (System Management section) and see if your IE client is keeping multiple sessions alive for various IE windows you open. (tested using IE 7.0.5730.13; MII 12.0).

[Former Member · Accepted solution]

Hi Ryan,

I had the same question and this is what I found (somewhere on the web...)

IE7, IE6 - All tabs or windows opened from clicks will share the same instance/session.

Starting IE from the IE icon will open up a "new" instance/session. You must use the IE icon, then you

can use a favorite link.

IE8 - IE8 model changed, so that all browser windows, tabs, etc., run under the same frame/session, much like Firefox.

Clicking the IE icon again now just keeps the same frame and thus the same session. IE8 introduced a new

feature - File Menu -> New Session. This will open up a new window that will be a separate frame that will not use

current session cookies.

Hope this helps.

--Amy Smith

--Haworth

[Former Member · Accepted solution]

Hi Amy,

thanks for this answer. I often run multiple instances of the portal (e.g. one with an administrator log-in, one with the end user view) and previously did that by clicking on the IE icon. With IE8, I noticed that this doesn't work anymore and was uncertain whether this is an issue caused by a specific setting in the IE8 properties. Well, now I know.

thanks again,

Fabian

[Former Member]

Hi Ryan,

Not going to reply straight to you question, but If you want your users to get the same experience whatever browser they are using, you'd better use parameters in the urls after they have filled the information in:

Something like: [http://...myReport.irpt?EmployeeNumber=000111&WorkCenter=WC00001]

Then use the token in you report as value for hidden fields. and that you can access through javascript or input etc...

If you run into the trouble of urls length limitation then you can generate a guid and store the information in a queue (iCommand -> xacute query -> transaction -> return the generated guid) and retrieve the information associated with that queue when you require it from either servlet or xacute query. Just don't forget to clean the queue on the closing event and also on the date... just the closing event is not enough.

That'll also give you the possibility to access it straight from any transaction.

The good point is that if they need to work on different information at the same time they just have to start on a new first page and it works.

I guess this is what you're already doing, but that might help

Cheers,

Arnaud

[HariCS23]

Ryan -

Can you try to accessing the application in IE6 with above scenario.

I corelated this issue with accessing two gmail accounts in single machine with defferent browser windows.

I observed that it work only with IE and more accurately with version 6.

In newer version of IE,new gmail session stays for some time and other session logsoff . So, bottom line is,newer version of IE's has some intelligence to avoid multiple logins .

I guess it worth to try once in IE6. ( 6.0.2900 sp2 )

Thanks

Hari