LCDS&Flex – 注销后防止DuplicateHTTPSession错误

这是堆栈的重要事实：

> Flex客户端在应用程序中具有登录/注销功能.注销后页面不刷新. (因此,Flex应用程序和基础mx.messaging.FlexClient仍保持初始化状态)
>用户可能打开多个选项卡.
> per-client-authentication设置为false – 我们正在尝试实现SSO(与CAS集成),因此用户原则绑定到JSession.
>使用长轮询进行消息传递时,以及打开两个(或更多)选项卡时,问题最为明显.
>使用RTMP或流式传输通道时,问题很难重现.
>用户绑定到JSession – 即,如果他们在Tab1上登录,他们将登录到Tab2.
>当用户从任一选项卡注销时,Jsession无效.

以下是我目前关于导致问题的理论：

> Tab1(T1)启动客户端 – >已发布ClientId1(C1) – > JSession1(J1)创建
> Tab2(T2)启动客户端 – >发布ClientId2(C2) – >加入J1
> T1登录 – > J1不受影响
> T2登录 – > J1不受影响
> T1& T2都订阅,开始轮询amflongpolling
> T1发送注销 – > J1无效 – > J2创建了
> T2发送民意调查(针对J1)
> T1注销完成,返回J2,更新cookie

最后两个调用产生冲突,LCDS看到FlexClient似乎与2个JSession相关.

结果,收到了以下错误：

Server.Processing.DuplicateSessionDetected Detected duplicate
HTTP-based FlexSessions,generally due to the remote host disabling
session cookies. Session cookies must be enabled to manage the client
connection correctly.

注意：我已经能够在独立项目中重新创建问题.我认为这不是我们的应用程序特定代码的问题,而是由状态/会话性质以及共享同一会话的多个选项卡之间的冲突引起的.

总之,我认为问题是由于来自一个选项卡的调用导致服务器上的会话无效,但是在将响应发送到浏览器以通知新的JSession之前,调用是在旧的Jsession下发出的. .

什么是适当的策略来抵御这个重复的会话问题？

更新

为了澄清,尽管该场景类似于here讨论的那些场景,但存在微妙的差异,这使得该文章中的解决方案不合适.

具体来说,本文讨论了通过使用JSP或协调的RemoteObject调用控制跨两个浏览器的JSession的初始创建来防止重复会话.

Flex实际上通过阻止出站RemoteObject调用来协助此过程,直到定义了本地FlexClient DSid变量,表明初始会话已建立.

我的场景不同,因为JSession(和相关的LCDS FlexSession /客户端FlexClient对象)已经建立一次(使用该文章中讨论的技术)并随后通过注销失效 – 调用session.invalidate() – 销毁JSession.

当Tab2使用陈旧的JSession发送调用时,会出现问题,这是一个重复的HTTP会话错误.然后情况变得复杂,因为当LCDS抛出DuplicateHTTPSession错误时,它也使与客户端连接的所有已知Jsessions无效,这意味着Tab1 – 一直没问题 – 现在有一个陈旧的JSession. Tab1下次发送呼叫时,IT会导致DuplicateHTTPSession错误,并且循环重复.

不幸的是,Flex框架挂钩用于在建立sesssions时延迟调用没有简单的方法(我发现)一旦设置就重新启用. (我试过以下,无济于事:)

// Reset DSid to get a new FlexSession established on LCDS
   use namespace mx_internal

   public function resetFlexSession()
   {
        FlexClient.getInstance().id = null;  
        // Note - using FlexClient.NULL_ID also doesn't work.
   }