我可以在一个项目中看到以下配置
<bean id="myFilterSecurityInterceptor"
class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
<property name="authenticationManager" ref="authenticationManager" />
<property name="accessDecisionManager" ref="accessDecisionManager" />
<property name="securityMetadataSource">
<security:filter-security-metadata-source>
<security:intercept-url pattern="/user/**" access="PERMISSION_VIEW_USER" />
.....
</security:filter-security-metadata-source>
</property>
</bean>
<bean id="accessDecisionManager"
class="org.springframework.security.access.vote.AffirmativeBased" >
<property name="decisionVoters">
<list>
<bean class="org.springframework.security.access.vote.RoleVoter" />
<bean class="org.springframework.security.access.vote.RoleVoter">
<property name="rolePrefix" value="PERMISSION_"/>
</bean>
</list>
</property>
问题1:-
我无法理解两个
class "RoleVoter"
的bean元素在这里扮演什么角色?我的意思是单身选民还不够吗?问题2:-
也下一个豆
na
me="rolePrefix" value="PERMISSION_"
属性有什么帮助?我对第二个问题的理解是,当用户尝试访问URL / user /时,RoleVoter会将授予的权限与该值进行匹配
根据访问属性(在本例中为PERMISSION_VIEW_USER)给出,并且也应以“ PERMISSION _”(作为rolePrefix的值)开头。
那正确吗?
我已通过[此链接] [1]确认了对问题2的理解。不要为此烦恼。
最佳答案
如果您有第二个问题的解决方案,那么那确实可以回答第一个问题。 RoleVoter
使用的default prefix是ROLE_
,因此它将忽略任何不匹配的属性。
添加具有自定义前缀的第二个投票者意味着将同时考虑到ROLE_
和PERMISSION_
都匹配的属性。但是,该行为与前缀无关,因此,除非有其他原因在应用程序中使用不同的前缀,否则,如果您只选择一个附加的前缀,它将更加简单。
另外,您可以使用较新的表达式语法进行访问控制,这可能更易于理解,并且根本不需要任何特殊的命名约定。