spring security与Tomcat基本授权冲突
有人在Tomcat下激活基本授权时遇到Spring Security登录的问题吗？
注销后加载登录页面时根本无法登录。如果您刷新页面并重试，一切都很好:)(。
Did someone face the problem with spring security login when basic authorization is activated under Tomcat?
It is simply impossible to login when the login page loaded after logout. If you refresh the page and try again, everything is fine :)(.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我找不到对这种行为的任何抱怨，花了一整天的时间来找出问题所在。最后发现原因是Tomcat的一个bug，该bug在6.0.20到6.0.28版本中都有（错误 49598）。
问题在于，Tomcat 的基本授权和 Spring 安全性在授权请求期间替换了会话。由于注销会使会话无效，因此在同一请求处理期间触发两个会话替换后直接登录请求。但是，在该错误的结果中，响应中的 Set-Cookie 标头仍然指向 Tomcat 给出的会话 ID（该 ID 会被 Spring 安全性失效，因为它会在之后工作）。因此，下一个请求将发送已销毁会话的 cookie。 Spring 创建的会话（包含签名用户）仍然无人认领。
最好的解决方案是 Tomcat 6.0.29 :-)。
如果有人在 Tomcat 升级时遇到问题，有 3 种可能性可以避免该错误：
禁用 Tomcat 的会话替换。您可以在 context.xml 中配置 Valve 来执行此操作
禁用 Spring security 配置 security.xml 的会话替换。
注销后提供额外的重定向。这样，Tomcat 将在登录请求期间在会话中缓存一个 Principle。
也许这可以防止有人像我昨天一样发疯:)
关于，
埃德加
I could not find any complain on such a behavior and spent whole day to find out the problem. Finally, it popped out that the reason is a bug in the Tomcat, which available in the versions from 6.0.20 to 6.0.28 (Bug 49598).
The issue is that the both, Tomcat's basic authorization and Spring security replace the session during authorization request. Since logout invalidates the session, direct login request after it triggers the both session replacements during the same request handling. But, in the result of the bug, Set-Cookie header in the response remains to point on the session id given by Tomcat (which gets invalidated by Spring security, since it works after). So, next request sends the cookie of already destroyed session. And the session created by Spring (which contains signed user) remains unclaimed.
The best solution is Tomcat 6.0.29 :-).
If someone has a problem with Tomcat upgrade, there are 3 possibilities to avoid the bug:
Disable session replacement of Tomcat. You can do this configuring the Valve in the context.xml
Disable session replacement of Spring security configuring security.xml.
Provide additional redirect after logout. This way Tomcat will have a Principle cached in the session during login request.
Maybe this protects someone of getting crazy like me yesterday :)
With regards,
Edgar