Question

我有一个非常简单的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嵌入了一个真正旧版本的commons-logging，它打破了webapp）。

我期望的行为是当我在webapp中请求资源时，WAS会重定向到form-login-page。

我看到的行为是，通过呈现登录表单而不是websphere保护安全资源，它直接进入应用程序内的spring security提供的“拒绝访问”。

我也尝试过BASIC而不是FORM作为auth方法，结果是一样的。

关于我可能做错的任何想法？

编辑：禁用Spring Security会导致声明性安全性按预期工作。这样得出的结论是，如果我想首先触发内置的LoginFilter，我必须在我的web.xml中明确声明它 - 让我对WAS依赖：O（

编辑：我还发现，在应用声明性安全性之前，WAS会触发应用中声明的过滤器;无论类加载器顺序如何，都会以这种方式发生。

备注：我启用了管理安全性，并正确映射了用户角色等。我使用websphere附带的“DefaultApp”验证了这一点，“snoop”servlet受到保护，挑战似乎在那个应用程序中正常工作。

Answer 1

因为你说webapp 非常简单，所以我会朝着另一个方向前进：从依赖项中删除commons-logging并依赖于WAS中的公共日志。 JCL很难从Websphere中解脱出来（例如，参见我试图帮助的其他问题：Explanation of class loading in an EAR for non-requested but dependent class）。流行的提示是切换到PARENT_LAST，但是相当多的人报告它不适用于他们。

浏览你的依赖项，看看JCL的依赖;如果您使用“nodep”罐子（包含所有依赖性的自包含），请将它们更改为单罐。 Maven是一个很好的帮手，如果你不使用它，那就是手工工作。

当classloader命令PARENT_LAST时，Websphere 7基于表单的身份验证被忽略

1 个答案: