>在运行IE7时运行IE7和项目经理的笔记本电脑时,我的笔记本电脑上的问题是100％可重复的.在运行FF的当前笔记本电脑上运行IE7或任何这些笔记本电脑时,问题都不会发生.
>问题仅发生在生产中 – 而不是在开发,内部分段或客户端分段上.生产是唯一的负载平衡环境,但上面提到的可重复性使我怀疑负载平衡是一个因素.
>当设置Session(“ID”)= 1的页面将响应发送回客户端时,我可以在所有情况下看到“Set-Cookie”标题,即创建ASP.Net_Session_Id cookie(并且它是HttpOnly).
>对服务器的后续请求将在未显示问题的计算机的标头中发送该cookie,但不在计算机上发送,因此要么删除cookie,要么忽略“Set-Cookie”标头.
>登录的方式如下：www.DomainX.com上的页面有一个iframe. iframe的来源是login.DomainY.com上的一个页面. login.DomainY.com提供的各种页面引导用户完成登录/注册过程. login.DomainY.com的最后一步是重定向到www.DomainX.com上的页面,包括查询字符串中的用户ID. www.DomainX.com上的此页面通常将ID存储在会话中,然后运行一些JS以将顶级文档重定向到新页面,从而将用户从iframe中取出.这是一个已经工作了几年的过程,具有DomainX.com的几个值.这里可能有所不同的一点是,在这种情况下,JS只是破坏了iframe和一些包含div的东西.
>我发现问题发生的情况与不存在问题的情况之间的另一个区别在于Google Analytics(分析)Cookie. login.DomainY.com/FinalStep.aspx将其重定向到iframe内的www.DomainX.com/SaveTheID.aspx有所不同.如果没有出现此问题,SaveTheID.aspx请求会包含各种Google Analytics Cookie(__ utma,__ utmz等).当问题确实发生时,此请求不包括所有GA cookie(它缺少__utma,__ utmz和__utmb).
>生产是login.DomainY.com在SSL下运行的唯一环境,所以我认为这可能是相关的.但我们暂时设置login.DomainY.com的暂存副本以使用SSL,但这没有任何效果.
什么可能导致这个？
编辑：生产环境包含www.DomainX.com和DomainX.com的域.还存在另一个已知问题,即没有为这两个域设置cookie.这可能是相关的,但是在修复产生之前我无法进行测试.
解决方法
处理此问题的其他一些方法是在负载均衡器上使用粘性会话(不推荐)或转移到无cookie的会话,这会起作用但可能会导致代码中的一些麻烦.
在我们的业务中,我们有一个主服务器和辅助服务器,后面有分布式缓存,这样如果一台机器发生故障,另一台机器可以接管.同样的原则适用于负载平衡,一旦您开始在应用程序池中拥有多台计算机或甚至多个实例,您就必须为此进行编码.
如果您使用Velocity进行会话,请确保您选择用于存储会话的缓存是不可删除的.
