当类加载器顺序 PARENT_LAST 时，Websphere 7 基于表单的身份验证被忽略
我有一个非常简单的 Web 应用程序，它将 spring 安全性与 j2ee 声明性安全性集成在一起。 web.xml 的重要部分如下所示：
<security-role>
<role-name>ROLE_USER</role-name>
</security-role>
<security-role>
<role-name>ROLE_SUPERVISOR</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>All Resources</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>ROLE_USER</role-name>
<role-name>ROLE_SUPERVISOR</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/accessdenied.html</form-error-page>
</form-login-config>
</login-config>
这在 Tomcat 6.0.33 和 Glassfish 3.1.1 中完全按照预期工作。当我将同一个应用程序迁移到 Websphere 7.0.0.17 时，我注意到我必须反转类加载器顺序，将其标记为 PARENT_LAST（因为 WAS 嵌入了一个非常旧版本的公共日志记录，这会破坏 web 应用程序）。
我期望的行为是当我在 web 应用程序中请求资源时，WAS 重定向到表单登录页面。
我看到的行为是，WebSphere 不是通过显示登录表单来保护受保护的资源，而是直接进入应用程序内 Spring Security 提供的“访问被拒绝”。
我也尝试过使用 BASIC 而不是 FORM 作为 auth-method，结果是相同的。
关于我可能做错了什么有什么想法吗？
编辑：禁用 Spring Security 会导致声明性安全按预期工作。 这样得出的结论是，如果我希望内置的 LoginFilter 首先触发，我必须在 web.xml 中显式声明它——给我一个对 WAS 的依赖：O(
EDIT：我还发现，WAS 在应用声明性安全性之前会触发应用程序中声明的过滤器；无论类加载器顺序如何，都会发生这种情况
注释：我有管理安全性 。启用并正确映射用户角色，我使用 websphere 附带的“DefaultApp”验证了这一点，“snoop”servlet 受到保护，并且挑战似乎在该应用程序中正常工作。
I have a very simple web-application that integrates spring security with j2ee declarative security.
The important parts of the web.xml are shown here:
<security-role>
<role-name>ROLE_USER</role-name>
</security-role>
<security-role>
<role-name>ROLE_SUPERVISOR</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>All Resources</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>ROLE_USER</role-name>
<role-name>ROLE_SUPERVISOR</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.html</form-login-page>
<form-error-page>/accessdenied.html</form-error-page>
</form-login-config>
</login-config>
This works exactly as expected in Tomcat 6.0.33 and Glassfish 3.1.1. When I migrated the same app to Websphere 7.0.0.17, I noticed that I had to reverse the classloader order marking it as PARENT_LAST (because WAS embeds a really old version of commons-logging which breaks the webapp).
The behavior I expect is for WAS to redirect to the form-login-page when I request a resource in the webapp.
The behavior I'm seeing is that instead of websphere protecting the secured resources by presenting the login form, it proceeds directly to the "Access Denied" supplied by spring security from within the app.
I've also tried BASIC instead of FORM as the auth-method, and the results are the same.
Any ideas as to what I might be doing wrong?
EDIT: Disabling Spring Security causes the declarative security to work as expected.
This sort of leads to the conclusion that if I want the built-in LoginFilter to fire first, I'd have to explicitly declare it in my web.xml --giving me a dependency on WAS :O(
EDIT: I also discovered that WAS fires the filters declared in the app before applying declarative security; it happens this way regardless of the classloader order.
Notes: I have administrative security enabled, and properly mapped user roles, etc. I verified this using the "DefaultApp" that comes with websphere, the "snoop" servlet is protected, and the challenge seems to work as normal in that app.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
既然您说 Web 应用程序非常简单，那么我会采取完全不同的方向：从依赖项中消除公共日志记录并依赖 WAS 中的日志记录。 JCL 很难从 Websphere 中根除（例如，请参阅我试图帮助解决的其他此类问题：Explanation of class loading in an EAR 用于非请求但依赖的类）。流行的提示是切换到 PARENT_LAST，但相当多的人报告这对他们不起作用。
检查你的依赖关系，看看 JCL 依赖什么；如果您使用“nodep”jar（独立包含所有依赖项），请将它们更改为单个jar。 Maven 是一个很好的帮手，如果你不使用它，那就只能靠手动工作了。
Since you say the webapp is really simple, I'd go in a whole other direction: eliminating commons-logging from your dependencies and rely on the one from WAS. JCL is quite tough to root out from Websphere (see, for example, other such problem I tried to help with: Explanation of class loading in an EAR for non-requested but dependent class). The popular hint is to switch to PARENT_LAST, but considerable number of people report it does not work for them.
Go through your dependencies and see what relies of JCL; if you use "nodep" jars (self-contained with all depencencies packed), change them to single jars. Maven is a great helper for this, if you don't use it, it's down to manual work.