从去年的七月份开始我陆陆续续写了三篇SpringSecurity相关的文章，幸得各位掘友捧场，反响还算不错，这也给了我极大的信心和动力，本来是打算继续写下去做成一个SpringSecurity系列，后来因为换工作的缘故，导致暂时搁置了，今天开始继续更新相关内容，希望大家多多支持👍。
今天的主题是:SpringSecurity如何进行过滤器链代理？
1. 外部容器与内嵌容器
在前文SpringSecurity自动配置这一章我们已经说过SpringSecurity会初始化一个名为springSecurityFilterChain的Bean，我们的请求实际就会被这个Bean进行处理。
但是SpringSecurity不会直接拿这个Bean进行处理，而是通过一个Filter进行代理，在这个Filter内部调用了这个Bean进行doFilter处理（实际是不是一层代理，而是多层）。
那我们其实可以将流程简化为下图：
看起来很简单，Spring只需要注册一个Filter再调用过滤器链就行了，但其实Spring不会直接注册一个Filter，它会把这个Filter注册成为一个Bean交给容器管理，再注册到Filter中。
这里涉及到一个问题，我们传统的注册Filter是直接定义Filter，而要把一个Filter先注册成Bean再注册到Filter中无疑会做些额外的事，所以Spring就提供了两个接口：
- WebApplicationInitializer - 打包为war包使用外部容器时使用
- ServletContextInitializer - 打包为jar包使用内嵌容器时使用
这两个接口的作用都是可以在Servlet容器启动后注册自定义的Filter/Listener并交给Bean工厂管理，唯一不同的就是在不同外部环境下会选取不同的生效接口。
一般来说，框架中会同时包含这两种接口的实现，保证在不同外部环境下都有一致的表现，比如SpringSecurity中就具有以下两个实现:
- AbstractSecurityWebApplicationInitializer - 外部容器处理类
- DelegatingFilterProxyRegistrationBean - 内嵌容器处理类
我们今天的内容也是以这两个实现类为入口进行深入了解，不过上文也说到了他们仅仅是注册Filter的入口不一样，注册Filter之后的后续代理流程还是一模一样的。
2. 内嵌容器方式注册Filter
现在都是微服务大行其道的时候了，一般来说我们的应用都是通过内嵌容器的方式进行运行，所以我们先来说说内嵌容器运行时的整个启动链路。
我们知道在SpringBoot中很重要的一个特性就是自动配置，在org.springframework.boot.autoconfigure.security包下放着SpringSecurity的自动配置类，我们着重来看SecurityFilterAutoConfiguration，这里面只有一个方法：
public DelegatingFilterProxyRegistrationBean securityFilterChainRegistration(SecurityProperties securityProperties) {
DelegatingFilterProxyRegistrationBean registration = new DelegatingFilterProxyRegistrationBean("springSecurityFilterChain", new ServletRegistrationBean[0]);
registration.setOrder(securityProperties.getFilter().getOrder());
registration.setDispatcherTypes(this.getDispatcherTypes(securityProperties));
return registration;
}
通过这个方法的方法名：securityFilterChainRegistration我们可以看出来该方法的作用就是为了注册过滤器链，同时我们看它的方法内容可以看到它创建了一个上文中提到过的DelegatingFilterProxyRegistrationBean的实例，传入的参数就是过滤器链的名称，由于此类是ServletContextInitializer的实现类，所以它最终会通过它的getFilter()方法创建一个Filter实例。
public DelegatingFilterProxy getFilter() {
return new DelegatingFilterProxy(this.targetBeanName, this.getWebApplicationContext()) {
protected void initFilterBean() throws ServletException {
}
};
}
这个DelegatingFilterProxy就是创建出的Filter实例，我们可以再深一步的看看它的实例化过程：
public DelegatingFilterProxyRegistrationBean(String targetBeanName, ServletRegistrationBean<?>... servletRegistrationBeans) {
super(servletRegistrationBeans);
Assert.hasLength(targetBeanName, "TargetBeanName must not be null or empty");
this.targetBeanName = targetBeanName;
this.setName(targetBeanName);
}
实例化的过程比较简单，就是将我们要代理的Bean的名字放在targetBeanName属性上面，然后这个Filter就相当于在我们容器的Filter链中了。
这其实这个时候我们要代理的Bean的实例还没被放到这个代理类中，目前这个代理类中只有targetBeanName属性。
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException {
Filter delegateToUse = this.delegate;
if (delegateToUse == null) {
synchronized(this.delegateMonitor) {
delegateToUse = this.delegate;
if (delegateToUse == null) {
WebApplicationContext wac = this.findWebApplicationContext();
if (wac == null) {
throw new IllegalStateException("No WebApplicationContext found: no ContextLoaderListener or DispatcherServlet registered?");
}
delegateToUse = this.initDelegate(wac);
}
this.delegate = delegateToUse;
}
}
this.invokeDelegate(delegateToUse, request, response, filterChain);
}
代理Bean最终的实例化是在第一次请求到达，调用doFilter方法时，判断之后发现目前并没有被代理对象，就会调用initDelegate方法：
protected Filter initDelegate(WebApplicationContext wac) throws ServletException {
String targetBeanName = this.getTargetBeanName();
Assert.state(targetBeanName != null, "No target bean name set");
Filter delegate = (Filter)wac.getBean(targetBeanName, Filter.class);
if (this.isTargetFilterLifecycle()) {
delegate.init(this.getFilterConfig());
}
return delegate;
}
这个过程也很简单，就是从Bean工厂中找到这个Bean，然后赋值给代理对象。
最后，将会调用invokeDelegate方法，调用被代理对象的doFilter方法：
protected void invokeDelegate(Filter delegate, ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException {
delegate.doFilter(request, response, filterChain);
}
其实到这就已经和之前的文章内容串联起来了，剩下的就可以交给代理Bean去做了，这个代理Bean就是我们在SpringSecurity自动配置这一章讲到过的springSecurityFilterChain。
然而其实我们可以继续深入，在那一章讲过这个Bean的类型是FilterChainProxy，我们可以看看它内部的doFilter又到底是怎么做的？过滤器链真的是一个链条吗？FilterChainProxy是直接代理这个链条吗？
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
boolean clearContext = request.getAttribute(FILTER_APPLIED) == null;
if (!clearContext) {
this.doFilterInternal(request, response, chain);
} else {
try {
request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
this.doFilterInternal(request, response, chain);
} catch (RequestRejectedException var9) {
this.requestRejectedHandler.handle((HttpServletRequest)request, (HttpServletResponse)response, var9);
} finally {
SecurityContextHolder.clearContext();
request.removeAttribute(FILTER_APPLIED);
}
}
}
这是FilterChainProxy的doFilter方法，上来就是一个if-else，但是他们会调用同一个核心方法doFilterInternal：
private void doFilterInternal(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
FirewalledRequest firewallRequest = this.firewall.getFirewalledRequest((HttpServletRequest)request);
HttpServletResponse firewallResponse = this.firewall.getFirewalledResponse((HttpServletResponse)response);
List<Filter> filters = this.getFilters((HttpServletRequest)firewallRequest);
if (filters != null && filters.size() != 0) {
if (logger.isDebugEnabled()) {
logger.debug(LogMessage.of(() -> {
return "Securing " + requestLine(firewallRequest);
}));
}
FilterChainProxy.VirtualFilterChain virtualFilterChain = new FilterChainProxy.VirtualFilterChain(firewallRequest, chain, filters);
virtualFilterChain.doFilter(firewallRequest, firewallResponse);
} else {
if (logger.isTraceEnabled()) {
logger.trace(LogMessage.of(() -> {
return "No security for " + requestLine(firewallRequest);
}));
}
firewallRequest.reset();
chain.doFilter(firewallRequest, firewallResponse);
}
}
在这个方法中会根据当前的请求去匹配能匹配到的Filters，具体操作在getFilters方法中，它的作用就是拿到FilterChainProxy的filterChains成员变量中的所有Filter，然后进行匹配，将匹配到的Filter封装成一个List。
乍听一下filterChains你可能已经不知道了，我们来看看它的类型：SecurityFilterChain，没错这是一个类，不要和前面的Bean搞混了，如果之前的文章你还记得那么可以知道这其实是由我们的自定义配置构建出的一个类，里面放了我们自定义相关的Filter。
如果我们有多个自定义配置文件就会有多个这样的对象，他们共同组成了filterChains。
如果能匹配到对应的Filter那么它会组成一个新的类：FilterChainProxy.VirtualFilterChain，这是一个内部类，然后进行doFilter操作，所以我们平常所说的过滤器链实际上是这个，它是真正起效果的那个类。
为了防止大家这一段看不懂、不理解、我特地画了一个图来形象的表示整个链路，只要对照我这个图再根据相关代码，相信可以很快的理解这一段的链路：
3. 外部容器方式注册Filter
刚说完了内嵌容器的方式，再来说说外部容器的方式，我在文章开头也说过，其实就是实现类的不同，注册完Bean后面的流程都是一样的，我先放个流程图给大家看看：
大家可以发现，其实只有最上面的两块发生了变化，所以如果上一节的内容好好看的话这一节的很快就能理解。
外部容器的情况下SpringSecurity的入口在AbstractSecurityWebApplicationInitializer，我再来重述一下它的作用：
- 继承了
WebApplicationInitializer - Servlet容器启动后会调用其实现类的
onStartup方法，在这里可以进行Filter的注册
在这个类中它通过调用了insertSpringSecurityFilterChain方法进行Filter的注册：
private void insertSpringSecurityFilterChain(ServletContext servletContext) {
String filterName = "springSecurityFilterChain";
DelegatingFilterProxy springSecurityFilterChain = new DelegatingFilterProxy(filterName);
String contextAttribute = this.getWebApplicationContextAttribute();
if (contextAttribute != null) {
springSecurityFilterChain.setContextAttribute(contextAttribute);
}
this.registerFilter(servletContext, true, filterName, springSecurityFilterChain);
}
这个方法其实也就是实例化了DelegatingFilterProxy，后续的流程都是一样了～～～
4. 结语
这三篇加上本篇一共四篇，大致已经将SpringSecurity的轮廓和关键流程勾勒出来了，工作中其实这么多内容也够了，我们公司就是用的SpringSecurity作为认证鉴权框架，相关代码链路也都能看懂😄
🏷️日后会支持输出更多后端内容，欢迎大家点赞收藏👏
