不再需要 Spring Security ROLE_ 前缀?

Posted

技术标签:

【中文标题】不再需要 Spring Security ROLE_ 前缀?【英文标题】:Spring Security ROLE_ prefix no longer needed? 【发布时间】:2012-01-09 00:35:27 【问题描述】:

我一直在研究如何创建自定义角色前缀,直到我意识到这并不重要。只要我在数据库中的角色与以下内容匹配:

<security:intercept-url pattern="/person/myProfile/**" access= "hasRole('BlaBla')" />

这不是示例,在 db 中,我确实设置了角色 BlaBla 进行测试,它可以工作。

我不喜欢我有不同的行为 - 许多人在设置自定义前缀来创建自定义角色时遇到问题。这里会发生什么,我应该期待隐藏的岩石吗?

我有 3.0.7 版本。在我对当局的查询中,我没有“默认”值...... 是版本造成的吗?

【问题讨论】:

【参考方案1】:

您可能正在使用:

 <http use-expressions="true"> 

配置一个 WebExpressionVoter,它将投票给拥有授予权限“BlaBla”(在您的情况下)的用户

请记住,受保护对象(例如 URL)的授权是由 AccessDecisionManager 执行的。

有三种具体的 AccessDecisionManager:肯定、共识和一致。

为了做出决定,他们使用 AccessDecissionVoters 列表。

RoleVoter,如您所愿,具有可配置的 rolePrefix(默认为 ROLE_)、AuthenticatdVoter 和新的 WebExpressionVoter。

不要忘记,AccessDecissionManager 及其投票者的组合可能会以您认为不合逻辑的方式允许或拒绝权限。

我建议您调试请求以查看 URL 和模式是否符合您的预期。

【讨论】:

我使用的几乎都是默认配置。所以我想我没有 AccessDecissionManager 和多个选民的组合。而且我的请求完全有效。(其他角色和匿名无法访问该资源)所以我猜这个 WebExpressionVoter 是罪魁祸首。总之很奇怪。那么什么时候选择roleVoter呢?它怎么知道选择哪一个?说方法级别的安全性仍然适用于 WebExpressionVoter? @Aubergine Voters 不是“选择”的:总是要求每个Voter 投票,然后AccessDecisionManager 结合所有投票做出最终决定。默认的AccessDecisionManagerAffirmativeBased,只要没有Voter 拒绝访问并且至少有一个Voter 允许访问,它就允许访问。请注意,Voters 可以(并且经常)弃权,AccessDecisionManager 通常将其解释为“我不介意这种访问尝试”。在您的情况下,WebExpressionVoter 允许访问,而另一个 Voters 弃权,因此最终授予访问权限。 对造成的误解深表歉意。我的意思是我不知道您的配置(您的 applicationContext-security.xml 的内容),但如果您使用带有安全命名空间的 use-expressions,则配置了 WebExpressionVoter。 @jbbarquero 我正在使用use-expressions=true 和 Spring Security 4.0.1 并且没有“ROLE_”前缀的任何角色都不起作用,我错过了什么吗? 检查this 问题。我认为你应该改用hasAuthority

以上是关于不再需要 Spring Security ROLE_ 前缀?的主要内容,如果未能解决你的问题,请参考以下文章

Spring Security:如何向经过身份验证的用户添加额外的角色

Spring Security 角色继承

Spring Security 中 Role 和 GrantedAuthority 的区别

Spring Security 中 Role 和 GrantedAuthority 的区别

带有 ROLE_ANONYMOUS 的 AngularJS 和 Spring Security 仍然返回 401

Spring Security应用开发(16)基于表达式的访问控制