IE7下不同用户会共享同一个session会话的问题

有人喜欢吃菜，有人喜欢吃肉，个人有个人的爱好。我觉得这本身不是BUG,所以也不用防止用户利用不同选项卡进行多用户登陆以规避该设计带来的潜在的风险。就我个人的开发经验就碰到过一次，客户要求在新打开一个TAB这样的情况，就用原来的用户数据自动登录的。所以我们只要知道浏览器有这个特性，以后开发时注意就好了。
到是楼主的问题，假设真的有楼主这样的需求，客户说要改，怎么办？我们该怎么用最小的代价来对应用进行重构？
如果我们能够把强制tomcat设置成通过URL中携带JsessionID的方式，那可以解决楼主的问题，但是楼主说应用不能关闭cookie,否则就运行有问题，那我们换个思路，强制tomcat设置成通过cookie的方式来携带JsessionID.然后做一个Filter,该filter会对每一个request进行检查:
String retUrl = request.getHeader("Referer");
通过这个方式获取request的上一个请求url,如果是null,就说明该请求是新页面访问(一个新的TAB)，
if(用户请求URL是Login.jsp&&retUrl==null){

}

有人喜欢吃菜，有人喜欢吃肉，个人有个人的爱好。我觉得这本身不是BUG,所以也不用防止用户利用不同选项卡进行多用户登陆以规避该设计带来的潜在的风险。就我个人的开发经验就碰到过一次，客户要求在新打开一个TAB这样的情况，就用原来的用户数据自动登录的。所以我们只要知道浏览器有这个特性，以后开发时注意就好了。
到是楼主的问题，假设真的有楼主这样的需求，客户说要改，怎么办？我们该怎么用最小的代价来对应用进行重构？
如果我们能够把强制tomcat设置成通过URL中携带JsessionID的方式，那可以解决楼主的问题，但是楼主说应用不能关闭cookie,否则就运行有问题，那我们换个思路，强制tomcat设置成通过cookie的方式来携带JsessionID.然后做一个Filter,该filter会对每一个request进行检查:
String retUrl = request.getHeader("Referer");
通过这个方式获取request的上一个请求url,如果是null,就说明该请求是新页面访问(一个新的TAB)，
if(用户请求URL是Login.jsp&&retUrl==null){
    request.getCookies,然后对cookies进行修修补补，再来个URL重定向什么的．
}else if(用户请求URL不是Login.jsp&&retUrl==null)｛
　　那不让他访问
｝else{
   该怎么着还怎么着．
}
这个方法是我的不成熟的想法，我也没有测试或者验证过，特别是：request.getCookies,然后对cookies进行修修补补，再来个URL重定向什么的．不知道行不行的通？

貌似行不通吧.

因为原窗口,和你在新的选项卡里打开的窗口共用一套cookie.
你对"对cookies进行修修补补",这样的话会影响到原窗口吧.

我也一直在研究这方面的问题.
我们的系统都上线了才被告知 客户需要在 ctrl+n 或者ctrl+t打开的窗口里换用户登录,同时保证已经打开的窗口登录信息不丢失.

其实要是早知道这样,当初就把session内的登录信息设置成支持多帐号的就好了,唉.事后补救似乎真的没有很好的办法啊.

继续关注

实际上如果采用"禁止用户在ctrl+n 或ctrl+t 打开的窗口里进行多用户登录操作"这样的方式,那问题就简单得多了.

通过很多技巧都能实现.但是我们的客户明确的说了"我们要用,你们的系统如果不支持,是你们的问题".

实际上 多用户登录这一情况是正常的(一个人有多帐号 多权限很正常),而使用ctrl+n 或ctrl+t等快捷键能够提高工作效率 而且符合用户习惯,这也是无可厚非的,所以我们很难采用"禁止客户...."的策略啊

基于这样一种考虑：
在同一窗口的不同页签中用相同的url（包括后面的参数）运行出不同的结果来是不可能的，因为他们发到后台的信息是完全一样的，相同的sessionid传递机制sessionid也相同。

那么要实现多页签登录多用户，只有用不同的url来实现。
有两种方法，一种是在url后面加上用户的参数，如？userid=ed3432432，每个url不管是post还是get方式都要加，后台要实现在一个session中能够管理多个用户的登录。还有个问题，就是多个用户共用cookie，因此不能正常使用cookie。

另一种方法是修改url中的域名部分，如javaeye中blog的域名：janh.iteye.com，实现泛域名解析，这种方式实际上每个用户的sessionid是不同的，因为sessionid的传递机制用cookie是识别域名的，不同的域名使用不同的cookie，因此每个用户得到是不同的session。

多个用户中每个用户打开多个页签也不会混淆，因为每个用户的域名是一样的，用的cookie也是一样的，在cookie中保存的其他信息也不会混淆。

在实现上，程序的处理上不用做任何改变，唯一要做的是在用户登录后重定向到他的域名地址，或者在登录页面根据输入的用户名直接登录相应的域名，后面的各个页面请求自动转到这个域名了，包括弹出的子页签也是跟的这个域名，但是要注意在页面的各个url链接中不要写全路径，只写域名后面的部分就行了，一般也都是这么写的吧。

实际上像阿里巴巴购物、网易邮箱都是用泛域名来做的。

另：实现泛域名解析只要在域名服务器上设置一项： *.iteye.com 指向61.152.145.77 就可以了。

看来原理决定了实在没有简介的解决方案啊。
不过第一种解决方案，还能有简单的方式么？这样的话要重构的地方实在太多了，要是我，肯定受不了

如果能改变web服务器的sessionid传递机制倒是能简单一点，比如不用cookie，把sessionid放在url跟的参数中，能实现一个用户一个session，即使这样，每个页面中的所有url都要加上这个sessionid也比较麻烦。

总结下解决办法：

1一种，在后台使用单session针对一个机器(IP)，然后通过唯一性标识绑定用户 进行区分，
类似在session中放一个Map<userid,Map<sessionKey,sessionValue>>

2另外一种思路我觉得更好，在client的页面上 设置hidden input 将seesionId携带，或者url携带sessionid，这样的好处是服务器不需要做改变，问题是client只有最后操作的用户的cookie使用上要更小心，会覆盖别的用户的cookie信息

3另外大家还提到了泛域名的方法，这个如果实现方便的话，应该是最好的吧


ps：
以前用dotnet的时候我们系统采用了类似2的方式，实现了多用户登陆的，运行良好。
很多同学不好好看贴，翻来覆去地不知道要搞什么，浪费时间。
总结如有问题请指正，谢谢。

问题的根源是浏览器的"TAB机制"引起的,
治本的满足客户的“需求”，应该动浏览器，而不是动设计。。定制一个浏览器，修改共享Session的"TAB机制"，这样一劳永逸