'陷害'tomcat6失去会议

时间:2017-05-29 14:25:07

标签: java jsp session tomcat6 genesys

IWS是一个桌面应用程序,它有自己的webBrowser组件,可在需要时调用Scripting web-app。脚本位于Tomcat6中。

脚本基本上是一个JSP应用程序。 (实际上它是一个引擎,通过其图形界面从人工操作构建JSP应用程序,如定义流程,按钮,内容等,但我在谈论它作为JSP生成的“脚本”)

我需要破解Scripting,以便它可以在IWS应用程序的webBrowser组件中共享空间(通过框架)。

IWS调用2次start.jsp:

  • 第一次以隐藏的方式(可能是来自IWS代码的直接http查询),没有任何特殊参数。原始start.jsp执行2 302(所以调用总共访问3页)它在cookie中作为参数使用jsesionId结束(但不是在最后302页)

  • 第二次,使用jSessionId和一堆重要参数。它仅使用jSessionId作为参数。据我在fiddler中看到,当jsessionId在其自己的内部时,没有使用cookie

所以我猜第一次只是为了得到一个新的jSessionId。

我现在尝试的解决方案是用新的框架页面替换Scripting起始页面,在它保留的两个框架之一中,它加载Web应用程序,第二个框架中的另一个应用程序。根据第一帧的数据,它将更新第二帧。

所以喜欢:

  • 我们有start.jsp ...(实际上它被称为不同的东西)

  • 我们以:

    结束
    • start.app.jsp(原始的start.jsp,刚重命名)

    • start.jsp(是包含html的新内容,包含上一个start.jsp)

新的start.jsp使用自己的url,将start.jsp更改为start.app.jsp,以在iframe中调用真正的Scripting应用程序。

但是我遇到了类似会话问题。我不是tomcat的专家。我了解到它用cookie或参数控制会话。我认为它配置为使用URL sessionId但我不太确定。我已设置META-INF / settings.xml以禁用会话中的cookie使用,但它仍会在cookie列表中显示cookie。

我的问题是,在第二次调用start.jsp时,它看起来比使用“旧cookie”之类的想法,忽略了URL中的jsessionId。 WWG00000E出现一些奇怪的错误:WWGAIL - 错误:没有为函数getInteractionKVPair提供ID详细信息:

它就像是用另一个jsessionid回到旧的cookie。每次出现错误时,那个'old'jsessionid都是一样的。

使用fiddler嗅探,我看到第二个start.jsp以URL中的右边jsessionId开头,但它的cookie就像是来自另一个会话,并且它停止为每个重定向添加jsession id,因为这发生了。它就像是在一个完全不同的宇宙中执行。这是正常的?????

目前我正在尝试无法强制使用cookie jSessionId以及链接以便它们包含jSessionId。

拜托,你有什么想法吗?

谢谢!

Edited2:如果我没有框架放置它(恢复默认的start.jsp)。在IWS只在第一次(交互)工作,而在任何后续的问题中,问题开始出现......

1 个答案:

答案 0 :(得分:1)

好的,终于解决了......

至少使用此版本的Tomcat:

  • 在没有jSessionId的情况下调用jsp会在您的app cookie中创建一个新的jSessionId。
  • 任何进一步的时间html请求将使用cookie jSessionId而不是URL上存在的cookie,因此您将丢失任何类型的多会话支持。

这是一个特殊的东西,而不是webBrowser组件,做两步连接,第一个请求永远不会有一个关联的cookie,所以它工作正常,给你一个新的jSessionId的cookie,然后你可以做一个新的, cookieless,第二个请求,它使用URL的jSessionId并且没有cookie或者没有"默认"没有jSessionId的cookie。当这个webBrowser在其URL中请求没有jSessionId的jsp页面时,如上所述,问题就开始了,所以如果第一个请求包含非jSessionIded调用,Tomcat会给你一个jSessionId,它在你的"默认应用cookie上设置#34 ;,所以第二个请求会忽略任何URL jSessionId以使用该cookie上的那个。

在网络浏览器中,我观察到至少在Firefox中,清除cookie并不足以消除这个"默认cookie"。但也许它可能是经典"它需要太长时间,所以你认为它是干净的,但实际上它不是"。不确定。

我知道这听起来令人困惑。我没有时间对此进行进一步测试。

据我所知,它就像是,当它工作正常时,它就像一个"会话cookie" (没有jSessionId),当它不起作用时,它需要"默认cookie" (使用jSessionId)并开始忽略URL jSessionId。

我已向Tomcat的dev邮件列表发送了一封电子邮件。 (一个说正确的地方是用户邮件列表......但是你在这里;-))