4

在 appSecurity.xml 我有这个：

拦截 url 模式="/users/profile/**" 访问="hasRole('VIEW_PROFILES')"。

拦截 url 模式="/users/profile/edit/**" 访问="hasRole('EDIT_PROFILES')"

我有一个页面 /users/profiles/edit/addnew ，当具有角色 VIEW_PROFILES 的用户尝试访问此页面时，他成功获取了该页面，但对具有角色 EDIT_PROFILES 的用户的访问被阻止。

我做错了什么？

4

3 回答 3

10

由于"/users/profile/edit/"比 更具体"/users/profile/"，因此应将其放在列表的较高位置。

为什么

模式总是按照它们定义的顺序进行评估。因此，更具体的模式在列表中定义得比不太具体的模式更高，这一点很重要。这反映在我们上面的示例中，其中更具体的 /secure/super/ 模式看起来比不太具体的 /secure/ 模式更高。如果它们被反转，/secure/ 模式将始终匹配，而 /secure/super/ 模式将永远不会被评估。

来源：核心安全过滤器

于 2013-04-14T15:35:07.650 回答
2

John Farrelly 和 Ritesh 都是正确的。模式按列出的intercept-url顺序匹配。一旦找到匹配项，指定的其余模式将被忽略。这就是为什么您应该更早地列出更具体的模式的原因。

在您的情况下，/users/profile/edit/somepage的模式与第一个模式中指定的模式匹配intercept-url，因此 Spring 正在适当地检查相关用户是否具有指定的访问角色。显然，您的 EDIT_PROFILES 用户没有 VIEW_PROFILES 权限，因此他们被拒绝访问。同样，您将 ../edit/ 访问权限限制为具有 EDIT_PROFILES 权限的用户的意图被前面的语句破坏了，该语句授予具有 VIEW_PROFILES 权限的用户访问权限。

切换顺序以进行简单修复，您可能希望授予 EDIT_PROFILES 用户 VIEW_PROFILES 权限（除了 EDIT_PROFILES 权限）。然后，考虑使用access="hasAnyRole('REQUIRED_ROLE')"而不是access="hasRole('REQUIRED_ROLE')", 来简化访问语句。

于 2013-04-22T16:21:09.843 回答
1

确保您的 EDIT_PROFILES 规则高于 VIEW_PROFILES 规则。如果您查看 VIEW_PROFILES 的表达式，您会发现它包含与 EDIT_PROFILES 匹配的每个 URL。这意味着如果 VIEW_PROFILES 规则是第一个，spring security 将永远不会尝试尝试 EDIT_PROFILES 规则。

于 2013-04-14T12:12:36.800 回答