How to avoid session sharing provided by IE8 programmatically in Java EE application?
Microsoft, in an effort to make Internet Explorer 8 "more stable" and “faster”, have changed the underlying architecture of the browser and introduced a function called "Loosely-Coupled IE" (LCIE) which works on session sharing across TAB and new instances.
But session sharing may be fatal when some one is trying to do two different things at a time with the same application, e.g. like someone want to book one forward journey ticket and one return ticket at a time, at that time he will book 2 same tickets what he has not intended to.
PROBABLE SOLUTION ON IT
While creating a new window instead of creating by clicking on an icon or Ctrl+N, we should use File -> New Session; it will not happen.
You can make a registry change on the client PC - adding the following.
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
“TabProcGrowth" = dword : 00000000
Will disable "Loosely Couple IE8"; IE8 then works as previous versions of IE.
- Run MSIE using
iexplore.exe -nomergewill disable "Loosely Couple IE8"; IE8 then works as previous versions of IE.
But how will I do it programatically?
You see, my problem is not my application. It's working fine if I am logging in one user, but when I am logging in multiple users through different users from different instances of IE8 browser, my later session data are overriding the former one, this is because both the IE browsers are using the same session id. It's happe开发者_运维百科ning because of session sharing of IE8. There is only one session maintained for one application however how many users I am logging in. In fact I want to mantain on session per user.
Like when I am logging in Gmail in one browser. If I am just typing Gmail on another browser. It's logging in automatically. I don't want this in my application. I should get login by another user at a time I should perform independent operation.
My application uses Struts, Spring, Hibernate & JBoss application server.
Now tell me how I should proceed?
I think the issues you describe above can be replicated on all browsers and can be better tackled server side. One approach I know of is to create a conversation id and manage the lifecycle of the conversation with a statemachine.
This allows you (and your users) to have one sesion where multiple conversations can be held concurently, which happens a lot in practice, well, at least in internal enterprise applications. The world is a more chaotic place than the business process models let show.
Your best bet is probably to use a web framework which supports multiple concurrent sessions (somtimes called conversations or flows), or just avoid using the session so much and go REST. If you need to hack it on the client, you would not be able to do it from your webapp, but a custom win program or a .reg file could do it. This also means that users with other OSs and browsers will still run into the same problem.
I did not like al the other solutions provided. The only thing I want is to provide a URL that the user can click and it gets a new session to login. There is a clear sessionAuthentication function but not a openLinkInNewSessionWindow
A work around for IE8 browser you could provide a link on the page "multiple login" and use the ugly WScript from the browser. An example:
<html>
<head>
<script>
function openNewSessionIE8NoMerge() {
// This opens a new session window for windows with IE8, unfortually there is a Active X security warning.
var WshShell = new ActiveXObject("WScript.Shell");
WshShell.Run("iexplore.exe -nomerge www.gmail.com?testNewSession");
}
</script>
</head>
<a href="#" onclick="javascript:openNewSessionIE8NoMerge();">Click here for a new session IE8 (multiple sessions on the same application)</a>
</html>
Test: Save the example in sampleNewSession.html, open the file with IE8, in a new tab login in gmail, press the link in sampleNewSession. Now there is a new window and not logged in.
This will help the user, it can just click a link. The only problem is the activeX security message.
Try to maintain the session id at client side. For example, at the JSP level. Then send it back to the server component and try tracking it. Say if the session received is in progress currently at server side, then hold for some time by synchronizing or a similar waiting mechanism. I hope this kind of session issues should be solved tricky.
加载中,请稍侯......
精彩评论