Spring Security权限管理（源码） 杂谈(2)

到此，应该明白AffirmativeBased、UnanimousBased、ConsensusBased三者的区别了吧，spring security默认使用的是AffirmativeBased， 如果有需要，可配置为其它两个，也可自己去实现。

##投票者
以上AccessDecisionManager的实现类都只是对权限（投票）进行管理（策略的实现），具体投票（vote）的逻辑是通过调用AccessDecisionVoter的子类（投票者）的vote方法实现的。spring security默认注册了RoleVoter和AuthenticatedVoter两个投票者。下面来看看其源码。

AccessDecisionManager boolean supports(ConfigAttribute attribute); boolean supports(Class<?> clazz); //核心方法，此方法由上面介绍的的AccessDecisionManager调用，子类实现此方法进行投票。 int vote(Authentication authentication, S object, Collection<ConfigAttribute> attributes); RoleVoter private String rolePrefix = "ROLE_"; //只处理ROLE_开头的（可通过配置rolePrefix的值进行改变） public boolean supports(ConfigAttribute attribute) { if ((attribute.getAttribute() != null) && attribute.getAttribute().startsWith(getRolePrefix())) { return true; } else { return false; } } public int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attributes) { if(authentication == null) { //用户没通过认证，则投反对票 return ACCESS_DENIED; } int result = ACCESS_ABSTAIN; //获取用户实际的权限 Collection<? extends GrantedAuthority> authorities = extractAuthorities(authentication); for (ConfigAttribute attribute : attributes) { if (this.supports(attribute)) { result = ACCESS_DENIED; // Attempt to find a matching granted authority for (GrantedAuthority authority : authorities) { if (attribute.getAttribute().equals(authority.getAuthority())) { //权限匹配则投通过票 return ACCESS_GRANTED; } } } } //如果处理过，但没投通过票，则为反对票，如果没处理过，那么视为弃权（ACCESS_ABSTAIN）。 return result; }

很简单吧，同时，我们还可以通过实现AccessDecisionManager来扩展自己的voter。但是，要实现这个，我们还必须得弄清楚一个东西，那就是Collection attributes这个参数是从哪儿来的，这个是个很关键的参数啊。通过一张官方图能很清晰的看出这个问题来：

接下来，就看看AccessDecisionManager的调用者AbstractSecurityInterceptor。

AbstractSecurityInterceptor ... //上面说过默认是AffirmativeBased，可配置 private AccessDecisionManager accessDecisionManager; ... protected InterceptorStatusToken beforeInvocation(Object object) { ... //抽象方法，子类实现，但由此也可看出ConfigAttribute是由SecurityMetadataSource（实际上，默认是DefaultFilterInvocationSecurityMetadataSource）获取。 Collection<ConfigAttribute> attributes = this.obtainSecurityMetadataSource() .getAttributes(object); ... //获取当前认证过的用户信息 Authentication authenticated = authenticateIfRequired(); try { //调用AccessDecisionManager this.accessDecisionManager.decide(authenticated, object, attributes); } catch (AccessDeniedException accessDeniedException) { publishEvent(new AuthorizationFailureEvent(object, attributes, authenticated, accessDeniedException)); throw accessDeniedException; } ... } public abstract SecurityMetadataSource obtainSecurityMetadataSource();

以上方法都是由AbstractSecurityInterceptor的子类（默认是FilterSecurityInterceptor）调用，那就再看看吧：

FilterSecurityInterceptor ... //SecurityMetadataSource的实现类，由此可见，可通过外部配置。这也说明我们可以通过自定义SecurityMetadataSource的实现类来扩展出自己实际需要的ConfigAttribute private FilterInvocationSecurityMetadataSource securityMetadataSource; ... //入口 public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { FilterInvocation fi = new FilterInvocation(request, response, chain); //关键方法 invoke(fi); } public void invoke(FilterInvocation fi) throws IOException, ServletException { if ((fi.getRequest() != null) && (fi.getRequest().getAttribute(FILTER_APPLIED) != null) && observeOncePerRequest) { // filter already applied to this request and user wants us to observe // once-per-request handling, so don't re-do security checking fi.getChain().doFilter(fi.getRequest(), fi.getResponse()); } else { // first time this request being called, so perform security checking if (fi.getRequest() != null) { fi.getRequest().setAttribute(FILTER_APPLIED, Boolean.TRUE); } //在这儿调用了父类（AbstractSecurityInterceptor）的方法， 也就调用了accessDecisionManager InterceptorStatusToken token = super.beforeInvocation(fi); try { fi.getChain().doFilter(fi.getRequest(), fi.getResponse()); } finally { super.finallyInvocation(token); } //完了再执行（父类的方法），一前一后，AOP无处不在啊 super.afterInvocation(token, null); } }