Tomcat上的Spring Security/JSF/Hibernate意外会话劫持？

Question

前几天发生了一件非常奇怪和令人尴尬的事情,我没有言语来形容发生的事情.

我的应用程序在Tomcat 7上运行与JSF 2.1,Hibernate 4,Spring Security集成的Spring 3.我通过电话与C级别的重要人员同时在同一页面上同时处于测试环境中.当他的页面出现我的个人帐户详细信息时,他开始导航到我正在浏览的页面.我不相信他,所以我走到他的办公室,果然,他不知何故登录了我的帐户,他没有密码.

该应用程序将保护患者的健康信息,因此我被命令向C级提供已发生事件的完整报告,但我无法确定这是如何实现的.我搜索了代码库,没有得到什么.我试图在多个场合重现确切的场景,但从未能够重现它.我甚至没有一个受过教育的猜测,我很满意.

我想也许在Tomcat应用程序上下文实现中存储的会话上可能存在一些不安全的线程操作,但如果它不可重现,我无法证明这一点.我还认为,由于Spring Security在其他请求和转发之前作为过滤器运行,可能其中一个servlet过滤器受到干扰.另外两个是我最近添加的Primefaces文件上传过滤器和Omnifaces SEO过滤器.

Omnifaces过滤器实际上干扰了Primefaces文件上传过滤器,我不得不修改它的配置,所以它们中的两个会很好地相互配合,所以我仍然觉得这也许是可能的.

Spring Security是否存在导致类似问题的已知错误？Tomcat是否存在与ApplicationContext意外服务错误会话状态有关的已知问题？是否有其他人遇到过类似的问题或对此有一些独特的见解？

编辑:发布后不久我发现了这个,仅在几天前发布:

会话混淆 - apache httpd与mod_jk,tomcat,spring security - 提供其他用户的数据

这几乎与我在Tomcat面前拥有Apache httpd + mod_jk插件的设置完全一样,所以我肯定不是疯了:)

更新:

我能够在没有mod_jk或Apache的情况下在我的开发环境中重现这个问题,所以我可以可靠地将其排除在外作为罪魁祸首.

Answer 1

我想到了 ：）

这是一种开发人员错误，但也是 Spring 的一个可笑的默认行为。我有一个名为 SessionBean 的 JSF 托管 Bean，我将其声明为@SessionScope. 当集成 JSF 和 Spring 时，JSF 依赖注入与 Spring 依赖注入冲突，因此 Spring 重写了处理该问题的 JSF 模块以仅包装 Spring DI。因此，当我将 JSF ManagedBean 声明为会话范围时，我还必须给它一个@Controller注释，以便它也被识别为 Spring Bean。

然而 Spring 并不理解 JSF@RequestScoped和@SessionScoped注释。Spring 有自己的注释，称为 simple @Scope(value = "request|session|singleton?|etc...")。

因为 Spring 无法识别我设置的 JSF 作用域，所以它在默认的 Bean 中将新创建的 Bean 视为 SINGLETON。

因此，每次有人登录时，它都会覆盖我用来缓存从身份验证主体获取的登录用户的属性。然后，每个执行任何操作的人都以不同的用户身份登录。

顺便说一句，Spring 的尼斯警告你，你错误地配置了你的该死的 bean。

感谢大家的帮助，希望这对未来的访客有所帮助！