针对 SpringSecurity 做了一个详细分析，让你明白它是如何执行的

纸上得来终觉浅，绝知此事要躬行。

不知道你们在使用SpringSecurity安全框架的时候，有没有想过 debug 一步一步看它是如何实现判断是否可以访问的？

如下：

@PreAuthorize("hasRole('ROLE_ADMIN')")
@RequestMapping("/role/admin1")
String admin() {
    return "role: ROLE_ADMIN";
}

为什么我们写上这个注解可以了呢？如何进行判断的呢？

前面写过一次‍ SpringSecurity 登录流程分析，写那篇文章是为了写‍ SpringSecurity 实现多种登录方式做铺垫。

那么这次写这个文章的原因呢？

在网上看到了他人写的 SpringSecurity 动态鉴权流程分析，才发觉用注解其实也不是个非常好的事情，直接固定在项目，无法做到动态的更改，是个要不得的事情（捂脸），之前只考虑到这么写蛮好的，看完文章才恍然大悟。这两天也准备实现一下Security的动态鉴权的小demo。

xdm，一定要记得，纸上得来终觉浅，绝知此事要躬行，尤其是一路 debug 的文章，亲身踩坑。

对于一门技术，会使用是说明我们对它已经有了一个简单了解，把脉络、细节都掌握清楚，我们才能更好的使用。

接下来就让‍来带大家一起看看吧。

二、流程图：

下图是在百度找的一张关于 Security 原理图

我接下来画的流程图是基于用户已经登录的状态下的画的。

整个认证的过程其实一直在围绕图中过滤链的绿色部分，而我们今天要说的鉴权主要是围绕其橙色部分，也就是图上标的：FilterSecurityInterceptor。

这也就是我流程图的开始，如下图：

上图如有不妥之处，请大家批正，在此郑重感谢。

关于上图的粗略解释，后文再一一道来：

1、登录后，用户访问一个需要权限的接口，经过一连串过滤器，到达 FilterSecurityInterceptor， FilterSecurityInterceptor 的invoke()方法执行具体拦截行为，具体是 beforeInvocation、finallyInvocation、afterInvocation 这三个方法，这三个方法是定义在父类 
AbstractSecurityInterceptor 中。

2、调用 
AbstractSecurityInterceptor 的 beforeInvocation 方法。AbstractSecurityInterceptor将确保安全拦截器的正确启动配置。它还将实现对安全对象调用的正确处理，即：

1. 获取访问当前资源所需要的权限SecurityMetadataSource..getAttributes(object);返回个 Collection< ConfigAttribute > attributes
2. 从SecurityContextHolder获取Authentication对象。 `Authentication authenticated = authenticateIfRequired();
3. 尝试授权 attemptAuthorization(object, attributes, authenticated); 调用 AccessDecisionManager 接口 decide 方法，执行鉴权，鉴权不成功，会直接抛异常。
4. 返回一个InterceptorStatusToken。

3、经过千辛万苦后，到达MethodSecurityInterceptor，由它再次重新调用起 
AbstractSecurityInterceptor.beforeInvocation(mi) 方法，来进行权限的验证

• 鉴权的时候，投票者会换成 PreInvocationAuthorizationAdviceVoter

进入正题前先放张图片缓一缓：

当乌云和白云相遇

---

三、前半部分

前半部分作用是在检测用户的状态，并非就是执行鉴权，不过两次都十分相近。关于方法上注解的检测是在后半部分。

1）入口：FilterSecurityInterceptor

第一步：FilterSecurityInterceptor void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)

//过滤器链实际调用的方法。 简单地委托给invoke(FilterInvocation)方法。
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    throws IOException, ServletException {
    invoke(new FilterInvocation(request, response, chain));
}

接着看 void invoke(FilterInvocation filterInvocation)

public void invoke(FilterInvocation filterInvocation) throws IOException, ServletException {
    if (isApplied(filterInvocation) && this.observeOncePerRequest) {
		//过滤器已应用于此请求，用户希望我们观察每个请求处理一次，因此不要重新进行安全检查
        filterInvocation.getChain().doFilter(filterInvocation.getRequest(), filterInvocation.getResponse());
        return;
    }
    // 第一次调用这个请求，所以执行安全检查
    if (filterInvocation.getRequest() != null && this.observeOncePerRequest) {
        filterInvocation.getRequest().setAttribute(FILTER_APPLIED, Boolean.TRUE);
    }
    
    //调用 beforeInvocation(filterInvocation) 方法 跟着这个方法往下看
    InterceptorStatusToken token = super.beforeInvocation(filterInvocation) ;
    try {
        //每个过滤器都有这么一步 
        filterInvocation.getChain().doFilter(filterInvocation.getRequest(), filterInvocation.getResponse());
    }
    finally {
        //在安全对象调用完成后清理AbstractSecurityInterceptor的工作。
        //无论安全对象调用是否成功返回，都应该在安全对象调用之后和 afterInvocation 之前调用此方法（即它应该在 finally 块中完成）。
        super.finallyInvocation(token);
    }
    //当调用afterInvocation（InterceptorStatusToken，Object）时，AbstractSecurityInterceptor不会采取进一步的操作。
    super.afterInvocation(token, null);
}

2）进入：AbstractSecurityInterceptor

授权检查 beforeInvocation() 方法

第二步：super.beforeInvocation(filterInvo