不再需要 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? @AubergineVoter
s 不是“选择”的:总是要求每个Voter
投票,然后AccessDecisionManager
结合所有投票做出最终决定。默认的AccessDecisionManager
是AffirmativeBased
,只要没有Voter
拒绝访问并且至少有一个Voter
允许访问,它就允许访问。请注意,Voter
s 可以(并且经常)弃权,AccessDecisionManager
通常将其解释为“我不介意这种访问尝试”。在您的情况下,WebExpressionVoter
允许访问,而另一个 Voter
s 弃权,因此最终授予访问权限。
对造成的误解深表歉意。我的意思是我不知道您的配置(您的 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 中 Role 和 GrantedAuthority 的区别
Spring Security 中 Role 和 GrantedAuthority 的区别