Понимание концепции RoleVoter?

Question

я могу увидеть ниже конфигурации в одном из проекта

<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" играет здесь? Я имею в виду, что не достаточно одного избирателя для голосования?

Вопрос 2: -

Также под один боб
, как это свойство на me="rolePrefix" value="PERMISSION_" помогает?

Мое понимание о втором вопросе, когда пользователь пытается получить доступ к URL/пользователь /, RoleVoter будет соответствовать предоставленным полномочиям в отношении стоимости данной против атрибута доступа (в данном случае PERMISSION_VIEW_USER), а также она должна начинаться с «РАЗРЕШЕНИЯМИ _» (заданное как значение rolePrefix). Это правильно?

Я понял свое понимание вопроса 2 с помощью [этой ссылки] [1]. Не беспокойтесь об этом.

Answer 1

Если у вас есть решение второго вопроса, это действительно отвечает на первый вопрос. default prefixRoleVoter использует ROLE_, поэтому он игнорирует любые атрибуты, которые не совпадают.

Добавление второго избирателя с индивидуальным префиксом означает, что будут учитываться атрибуты, соответствующие как ROLE_, так и PERMISSION_. Однако поведение не зависит от префикса, поэтому, если у вас нет другой причины иметь разные префиксы в вашем приложении, было бы проще, если бы вы просто выбрали одну из них.

В качестве альтернативы вы можете использовать новый синтаксис выражений для контроля доступа, который, вероятно, легче понять и вообще не требует каких-либо специальных соглашений об именах.