文章目录
一、 分析
在上面Spring Security + Jwt 项目的搭建过程中,我一直有一个问题。我们假设我们使用addFilterAt(A, B.class)。 即将A拦截器添加到B拦截器的位置。那么addFilterAt 既然没有覆盖原先的拦截器,那么A不是在B拦截器前面就是在B拦截器后面,那么岂不是和addFilterBefore 或者 addFilterAfter 重复了?
然而元芳告诉我没那么简单。最下面有总结,不想看源码的小伙伴可以直接看总结。
通过断点看到。我们通过添加拦截器的代码是这个样子的。
那么我们看源码:
0. FilterComparator
为了更好的理解后面说的内容,我们需要先了解一下 FilterComparator
这个类。顾名思义,这个类是一个过滤器比较器。可以看到如下
其比较的规则如下, getOrder是根据类名来获取到过滤器的序号。可以看到过滤器的排序是根据排序序号的大小来排序的,序号小的在前,大的灾后。
public int compare(Filter lhs, Filter rhs) {
Integer left = getOrder(lhs.getClass());
Integer right = getOrder(rhs.getClass());
return left - right;
}
我们这里拿 addFilterAt
举例,addFilterBefore
和 addFilterAfter
类似
1. HttpSecurity#addFilterAt
一句一句看,先看第一句
1.1 this.comparator.registerAt(filter.getClass(), atFilter);
这里的 方法是 在 FilterComparator#registerAt
中
这里可以看到,当我们使用addFilterAt 添加过滤器时,他添加的排序序号是和我们指定的拦截器相同的。()
public void registerAt(Class<? extends Filter> filter,
Class<? extends Filter> atFilter) {
// 获取 atFilter 的顺序
Integer position = getOrder(atFilter);
if (position == null) {
throw new IllegalArgumentException(
"Cannot register after unregistered Filter " + atFilter);
}
// 将filter放入 filterToOrder 中, filterToOrder 是一个map集合
put(filter, position);
}
....
private void put(Class<? extends Filter> filter, int position) {
String className = filter.getName();
filterToOrder.put(className, position);
}
// 调用 addFilterBefore 时使用这个方法注册,这里可以看到排序序号比指定过滤器要小1
public void registerBefore(Class<? extends Filter> filter,
Class<? extends Filter> beforeFilter) {
Integer position = getOrder(beforeFilter);
if (position == null) {
throw new IllegalArgumentException(
"Cannot register after unregistered Filter " + beforeFilter);
}
put(filter, position - 1);
}
// 调用 addFilterAfter 时使用这个方法注册,这里可以看到排序序号比指定过滤器要大1
public void registerAfter(Class<? extends Filter> filter,
Class<? extends Filter> afterFilter) {
Integer position = getOrder(afterFilter);
if (position == null) {
throw new IllegalArgumentException(
"Cannot register after unregistered Filter " + afterFilter);
}
put(filter, position + 1);
}
简单来说,就是我们 添加的 jwtLoginFilter
拦截器和 UsernamePasswordAuthenticationFilter
的序号是相同的。
1.2 HttpSecurity#addFilter(Filter filter)
代码很简单,如下,将添加的过滤器加到 filters 集合中
public HttpSecurity addFilter(Filter filter) {
Class<? extends Filter> filterClass = filter.getClass();
if (!comparator.isRegistered(filterClass)) {
throw new IllegalArgumentException(
"The Filter class "
+ filterClass.getName()
+ " does not have a registered order and cannot be added without a specified order. Consider using addFilterBefore or addFilterAfter instead.");
}
this.filters.add(filter);
return this;
}
通过断点我们还可以发现,我们手动添加的过滤器是先于大部分系统过滤器被加入到filters集合中的。这一点可以从断点中看到
另外从 HttpSecurity#performBuild
方法中我们可以知道,filters 在添加完所有过滤器后,使用 FilterComparator
比较器进行了比较。结果呼之欲出。
二、总结:
FilterComparator
比较器中初始化了Spring Security 自带的Filter 的顺序,即在创建时已经确定了默认Filter的顺序。并将所有过滤器保存在一个filterToOrder
Map中。key值是Filter的类名,value是过滤器的顺序号。- 当我们调用
HttpSecurity#addFilterAt(A, B.class)
方法时(其中B一定是先于A添加,或者B本身就是默认的过滤器),他会将我们的添加的过滤器A在FilterComparator
,并给给我们一个和B相同的序号(addFilterBefore(A, B.class) 给A的序号比B小1,addFilterAfter(A, B.class) 给A的序号比B大1)。同时,HttpSecurity#addFilter(Filter filter)
会将我们添加的过滤器添加在filters
List集合中, 而在List集合汇总我们手动添加的拦截器在除了WebAsyncManagerIntegrationFilter
之外的所有系统默认的拦截器之前。 - 最后Spring Security 会调用
HttpSecurity#performBuild
方法,在这里会使用FilterComparator
比较器对filters
进行比较排序,序号小的在前,序号大的在后,序号相等则按照原先的filters中的顺序。 - 由于在
filters
List集合中,我们自己添加的过滤器要在除了WebAsyncManagerIntegrationFilter
之外的所有系统默认的拦截器之前。导致了当我们调用了HttpSecurity#addFilterAt(A, B.class)
方法时,A拦截器要先于B拦截器执行。
举例(为了好理解,纯属假设):
- 假设Spring Security 里面默认拦截器 有A、B、C 三个(在强调一遍,假设有这三个),那么
FilterComparator
构造函数中就有这三个拦截器的顺序值,假设Map值为{“AcName” : 100, “BcName” : 200, “CcName” : 300}。其中AcName是A拦截器的类名,BC同理,100,200,300是他们的序号,用于确定顺序。 - 我们添加一个拦截器 F 要调用addFilterAt(F, B.class)。那么它首先会在
FilterComparator
中注册F (保存在排序Map中),排序序号和B相同,也为 200,这时候Map 就变成了{“AcName” : 100, “BcName” : 200, “CcName” : 300, “FcName” : 200}。(如果调用addFilterBefore F的序号就会减1,变成199; 如果调用addFilterAfter F的序号就会加1,变成201) - 在 完成上述步骤后,
HttpSecurity
中也会把 F拦截器添加到一个待排序的List集合L中,然后在添加其他系统默认过滤器(相当于这个List保存了所有的过滤器,但是其调用顺序未确定,还需要经过排序后才能确定)。最终List集合L就变成了{ A, F, B, C} (之前写成了F,A,B,C了,经评论区指正,已修改),注意这个是未经排序的过滤器集合,排序后才是真正的调用顺序。
4.在调用HttpSecurity#performBuild
方法时,会将HttpSecurity
中的过滤器集合L进行排序,排序比较器就是FilterComparator
,排序规则就是谁的排序序号小谁在前,序号大的在后,序号相同的保持 L 中的顺序。然后,得出最后的过滤器顺序,也就是最终调用顺序。
(讲的略乱,我已经尽力了。。。)
以上:内容部分木有参考
如有侵扰,联系删除。 内容仅用于自我记录学习使用。如有错误,欢迎指正