spring security的内部filter

咱们在用spring boot 配合spring security和oauth2的时候常常会把这两个类都用上，网上不少教程都没有告诉咱们他们之间的关系是什么？若是同时在处理同一个Url（如：/api/**）应该是哪一个生效？spring security的内部filter是个什么样子？带着这些疑问咱们一层层的来扒开。

spring security的内部filter是个什么样子？

Java在正常servelet处理http的请求可能会通过不少的filter，大致例子像下面这个：

图片.png

而spring security又是怎么处理的呢，详见下图：

图片.png

从图中能够看出spring security本身有一个叫FilterChainProxy代理类，该类也实现了servlet接口。FilterChainProxy``内部有一个List<SecurityFilterChain> filterChains,而SecurityFilterChain是一个接口也是一个chain，每一个chain里有若干个filter.既然有多个filter chain，那么来了一个http请求，这个请求（经过该请求的url来判断）应该由哪一个或者哪些filter chain来进行处理呢？在spring security里一个请只会被一个filter chain进行处理，也就是spring security经过遍历filterChains这个集合时，只要找到能处理该请求的filter chain就再也不进行其余的filter chain匹配。以下图：`

图片.png

好比来了一个请求，url是：/foo/**，那么他会被会第一个filter chain处理，后面的两个filter chain会被忽略掉。`

当咱们在spring boot引入了spring-security的相关包时，security默认会为咱们建立一个默认WebSecurityConfigurerAdapter，他拦截全部的http请求(/**),且这个Order的值是：SecurityProperties.BASIC_AUTH_ORDER。Security默认还会为咱们建立一些filter：

 

图片.png

每一个filter的做用能够在spring security中文档中找到。

固然你能够经过配置文件设置security.basic.enabled=false 来让默认的失效，或者你能够自定义一个并添加@Order值更低的WebSecurityConfigurerAdapter (or WebSecurityConfigurer) 的`@Bean``，好比像下面的代码：

@Order(SecurityProperties.BASIC_AUTH_ORDER - 10)

public class ApplicationConfigurerAdapter extends WebSecurityConfigurerAdapter {

 @Override

 protected void configure(HttpSecurity http) throws Exception {

 http.antMatcher("/foo/**")

 ...;

 }

}

若是同时在处理同一个Url（如：/api/**）应该是哪一个生效？

WebSecurityConfigurerAdapter与ResourceServerConfigurerAdapter同时在的话且都配置了处理url为：/api/**，默认是后者会生效。咱们在写ResourceServerConfigurerAdapter时，基本上会这么写：

图片.png

为何是后者生效呢，由于默认的WebSecurityConfigurerAdapter里的@Order值是100（咱们能够在该类上能够明确看到@Order(100)），而咱们在ResourceServerConfigurerAdapter上添加了@EnableResourceServer注解，这个玩意儿是干什么用的呢？他其中之一就是定义了@Order值为3（该注解里引用了ResourceServerConfiguration，这个类里面定义了Order值）.在spring 的体系里Order值越小优先级越高，因此ResourceServerConfigurerAdapter优先级比另一个更高，他会优先处理，而WebSecurityConfigurerAdapter会失效。

若是咱们想让WebSecurityConfigurerAdapter比ResourceServerConfigurerAdapter优先级高的话，只需要让前者的@Order值比后者的@Order值更低就好了。

注意：咱们每声明一个*Adapter类，都会产生一个filterChain。前面咱们讲到一个request（匹配url）只能被一个filterChain处理，这就解释了为何两者Adapter同时在的时候，前者默认为何会失效的缘由。咱们能够在FilterChainProxy中的getFilters(HttpServletRequest request)方法中能够看到有哪些filter chain，并处理哪些url，例如：

图片.png

 

a.若是咱们经过这种方式配置的话，requestMatcher值为显示No fields to display:

 

图片.png

b.若是经过这种方式配置的话，requestMatcher值为显示match到的url :/aa/**

图片.png

具体为何，见下文。

他们之间的关系是什么？

他们所属的功能模块不一样，前者spring security的，后者是spring security oauth2里的。他们都是Adapter，他们都会产生一个filter Chain，他们二者能够相互配合来对不一样的Url进行权限控制。

可是，咱们常常在写代码的时候常常会出现这种状况，当咱们在作oauth2的时候，当把两个类同时放在项目的时候，都声明了对http url的不一样处理，可是就是ResourceServerConfigurerAdapter会把的http配置信息彻底被覆盖掉，最后造成了，全部的请求只会在ResourceServerConfigurerAdapter的fitler chain中处理，致使用户不知道这二者究竟是怎么回事。

这实际上是由于对spring security的配置不熟悉致使的，也就是antMatcher()``和authorizeRequests().antMatchers()。

让咱们看两个例子：

例1：

图片.png

 

图片.png

上面这个例子，本意是想/api/* 端点需要被认证且要有USER权限;/user/**的端点需要被认证，可是最终的结果是WebSecurityConfigurerAdapter相关的配置信息没生效。

咱们使用postman来测试一下：

 

图片.png

图片.png

从这结果咱们能够看出来：/user/* 的端点没有被保护起来，/api/*的端点实际是被ResourceServerConfigurerAdapter产生的filter chain进行处理的。

这和咱们想要的效果不同呢，该怎么办呢，咱们来看看例子2：

例2：

 

图片.png

 

图片.png

postman测试：

图片.png

 

图片.png

能够看出来/api/的端点实际是被ResourceServerConfigurerAdapter产生的filter chain进行处理的。而/user/ 的端点也被保护起来，可是此次被处理的是由WebSecurityConfigurerAdapter产生的filter chain进行处理的。

让咱们来看stackoverflow上的解释：

图片.png

大致意思就是antMatcher()``是HttpSecurity的一个方法，他只告诉了Spring我只配置了一个我这个Adapter能处理哪一个的url，它与authorizeRequests()没有任何关系。

而后使用authorizeRequests().antMatchers()是告诉你在antMatchers()中指定的一个或多个路径,好比执行permitAll()或hasRole()。他们在第一个http.antMatcher()匹配时就会生效。

因此，WebSecurityConfigurerAdapter与ResourceServerConfigurerAdapter同时使用，其实和spring security的多个HttpSecurity配置是同样的，原理也差很少是同样的。

用官方的例子：

图片.png

一、按照正常的方式配置验证

二、建立一个包含 @Order的 WebSecurityConfigurerAdapter实例来指定哪个 WebSecurityConfigurerAdapter应该被首先考虑。

三、 http.antMatcher代表这个 HttpSecurity 只适用于以 /api/开头的URL。

四、建立另外一个 WebSecurityConfigurerAdapter实例。若是URL没有以 /api/开头，这个配置将会被使用。这个配置在 ApiWebSecurityConfigurationAdapter 以后生效，由于其含有一个 @Order值为1.没有 @Order默认是最后一个生效。