ie8 火狐 session 问题

Question

问题描述：
     
      ie8和火狐都可以选项卡的形式打开网页，以前ie6开多个窗口，在任务管理器中会出现多个explore.exe的进程，但是火狐不会。以前还认为这样很还，因为它可以减少我们电脑的压力，达到一定的选项卡数量后才又开启一个进程，就是说当我打开多个网页的时候它的会话也是共用的。      比如我现在在ie6上，打开一个登录页面，登录A人员信息。此时我再打开一个ie6的浏览器打开同样的登录页面，登录B人员信息，ie6能达到预期效果，让A,B同时在线。      现在我用ie8按照上面的步骤操作，当我打开B页面时，我再刷新A页面，A页面的信息变成了B页面人员的信息。因为ie8和火狐一样它会session共享，会认为是在同一个session，第二次提交修改了session的值。     那么现在要怎样解决ie8这个session失效的问题呢？如何在ie8上也有ie6,ie7的效果呢？找了些解决方法：
1：用户通过菜单 File > New session 打开新窗口，或者使用命令行参数 iexplore.exe -nomerge 来打开IE。
这样是基于浏览器解决，客户肯定是不懂的了，也不可能每个客户都去教。这很不现实。2：SESSION key 不使用COOKIE传递 使用URL传递就可以做到
可以借鉴网易邮箱地址栏参数  url传递sessionid这个倒是可以一试，不过不知道具体应该如何做？
而且我发现，其实我们跳转的时候好像地址栏后面是会自动跟着sid=XXXXXXXXXXXXXXXXX的。
http://localhost:9091/hotel_manage/loginUser.htm;jsessionid=D9273B75DB10E9BA5D88B87A7ED04F29请教各位，这第二种方案适用url传递如何做？
参考资料：我们可以使用url转发的方式，在客户端cookie被禁用的时候，把服务器端发送过来的JSESSIONID用下面的方式保存在url里http://localhost:8989/session1/session/testsession123.jsp;jsessionid=F1543A66EB5C7930D2CED3EFE3958BA1注意这里的格式，中间有一个分号有两种获得url转发的方法方法1：这个标签的作用是：把对应helloEncodeRul.jsp的页面，进行URL重写以后，把重写后的url放置到page中，这个时候，用"${pageScope.myurl }"就可以取到这个url重写后的url<c:url var="urltest" scope="page"  value="helloEncodeRul.jsp"></c:url> <a href="${pageScope.myurl }">TestSession</a>使用了整个标签以后，当前页面就会在第一次访问服务器的时候把服务器发送过来的JSESSIONID保存在url后面，用“；”分开，大概就是这个样子;jsessionid=F1543A66EB5C7930D2CED3EFE3958BA1 方法2.<a href="<%= response.encodeURL("testsession123.jsp") %>">TestSession</a><br> 一般情况下，推荐使用前一种方法。 当cookie被禁用以后，可以使用url重写的方式来获得客户端发送过来的JSESSIONID，整个时候整个JSESSIONID就会被保存在显示的拼接在url后面。

Answer 1

反正你通过网页、服务器代码是不行的。如果只是为了测试两个IE session可以，
文件>新建会话，或者运行命令行
iexplore.exe -nomerge参考

Answer 2

此Session非request.getSession()，cookie也分会话的，比如JSESSIONID

Answer 3

补充一下，也就是说，属于会话类型的cookie，在同一个客户的浏览器里面（当然属于不同进程/会话），可以同时有2个版本。

Answer 4

session的id实际上也是存在cookie里的啊。
这个问题没办法解决吗？
所谓的：
文件>新建会话，或者运行命令行
iexplore.exe -nomerge
这样的方式决定是不可行的。
一个网站肯定不会教每一个点击网站的人

Answer 5

不是和你说了，如果只是为了测试可行性还有方案。而且，IE6那个特性其实会导致更多的BUG，比如：
window.open(someUrl, "某个固定的窗口名字")，
如果那个“固定名字的窗口”已经由两外一个进程打开，会导致sessionA的人看到sessionB的信息。

Answer 6

你那个需求，AFAIK，对于普通用户无解，包括IE6用户（普通人分不清进程的区别），而且也是senseless的

Answer 7

如果他是普通客户，绝对不会说2个session或什么cookie的，你把他的原始需求说一下（不要加上自己的理解），大家帮忙看看有什么办法绕过去。如果他有技术背景，大可以两手一摊，让他自己解决，甚至可以对这种无理要求和他吵一架。

Answer 8

是网站，还是内部系统？？如果是企业内部系统，你可以发他们两个ie的快捷方式，里面写上iexplore.exe -nomerge http://xxxx/?session=1 <-- 这个参数随便，建议在入口加一下
iexplore.exe -nomerge http://xxxx/?session=2之类，然后强制该企业用户以这个入口进。

Answer 9

我觉得这个问题要深入到web容器是如何创建session,如何向客户端写cookie及通过sessionid查到对应session对象的。我曾经尝试过去查tomcat的代码,可惜半天没找到...郁闷。我觉得web容器session的机制是关键。估计是一个用户的一个浏览器进程访问服务器，服务器new 一个session,并将sessionid作为cookie的键值对写入客户端浏览器进程的内存区域中。估计cookie的名字是不是类似于域名？？所以通过新选项卡访问同一域名，cookie的名字和之前生成的一样，造成了覆盖，sessionid的值就为新的值了！如果是这种情况的话，问题就在于cookie的命名问题了。或者说，cookie中不应该存储sessionid这个唯一的名字...但又能怎样解决呢？没路可走啊....自己new session，然后通过url+jsessionid这种sessionid重写方式值得一试（排除了cookie的影响），但是new session不是自己通过程序能控制的吧，因为他是web容器控制的(容器有没有扩展方法，让程序员控制呢？)....还有一个新想法，我们可以不用session来存储用户信息（session.setAttribute("visitor",user);）。
而是在session中这样：当一个用户登录，session.setAttribute("192.168.1.1:2010-5-22:21.26.000",user); ，然后在所有的url中加上browserCardId="192.168.1.1:2010-5-22:21.26.000"（类似于jsessionid了）。那这样就可以避免了冲突了~~多个浏览器选项卡是共享了session,但是各自的信息是分开的。没有登录的选项卡，browserCardId就为空嘛~~我还没试，楼主试试吧，继续关注中！！！！！

Answer 10

分析错了，通过新新选项卡访问同一域名（应该同时查找本域名下的cookie,将sessionid一起传到服务器），所以找到了之前创建的session,不会new 一个session,所以不会有新的cookie产生。cookie覆盖就无从说起了。都是推测，如果有明白的，分享下啦~~

Answer 11

对于你的这个想法，我想你是把session.setAttribute（"name"，value）;name属性创建于当时的时间了吧？
那么这个属性你怎么确定？这个思路我觉得应该和上面url+sessionid是同一个道理吧？
我一开始是想的后台去判断sessionid，可是后来我发现新打开一个窗口的时候sessionid根本就是相同的。
所以我同意你说的，将sessionid保存在cookie中时的这种情况。应该问题是出在这里了。
新打开一个窗口的时候不能新建一个实例这就没有办法了。
我觉得这个问题还是在于浏览器打开窗口时不会新开一个进程不会新创建对象造成的。

Answer 12

可以用JavaScript中的unload和beforeunload事件来判断是否关闭浏览器或离开页面。但是这是不妥的，因为你要想到有些用户是禁用了JavaScript的。而且将登陆信息放到数据库中好像不能能解决session覆盖问题吧？

Answer 13

可以这样嘛，当客户端登陆。我们将在后台获得用户的IP，登陆时间。组合为browserCardId,然后再跳转到新的页面，url要加上一个browserCardId参数,还要将browserCardId存入request中。页面上的所有链接都用el表达式方式得到browserCardId值（之前存入了request中）。这样就将browserCardId一直传递下去...

Answer 14

我也遇到 两个ie8 共享session 的问题了，怎么解决呀？

Answer 15

http://www.cbrother.com/html/2233.html