过滤器链加载原理

简介: 通过分析DelegatingFilterProxy、FilterChainProxy与SecurityFilterChain源码,揭示了Spring Security过滤器链的加载机制:由web.xml中配置的DelegatingFilterProxy代理,通过Bean名称获取FilterChainProxy实例,再封装多个SecurityFilterChain,最终将15个安全过滤器依次注入执行,实现请求的安全控制。

通过前面十五个过滤器功能的介绍,对于SpringSecurity简单入门中的疑惑是不是在心中已经有了答案了呀? 但新的问题来了!我们并没有配置这些过滤器啊?它们都是怎么被加载出来的?
1-DelegatingFilterProxy
我们在web.xml中配置了一个名称为springSecurityFilterChain的过滤器DelegatingFilterProxy,接下我直接对 DelegatingFilterProxy源码里重要代码进行说明,其中删减掉了一些不重要的代码,大家注意我写的注释就行了!
public class DelegatingFilterProxy extends GenericFilterBean {
@Nullable
private String contextAttribute;
@Nullable
private WebApplicationContext webApplicationContext;
@Nullable
private String targetBeanName;
private boolean targetFilterLifecycle;
@Nullable
private volatile Filter delegate;//注:这个过滤器才是真正加载的过滤器
private final Object delegateMonitor;
//注:doFilter才是过滤器的入口,直接从这看!
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?");
}
//第一步:doFilter中最重要的一步,初始化上面私有过滤器属性delegate
delegateToUse = this.initDelegate(wac);
}
this.delegate = delegateToUse;
}
}
//第三步:执行FilterChainProxy过滤器
this.invokeDelegate(delegateToUse, request, response, filterChain);
}
//第二步:直接看最终加载的过滤器到底是谁
protected Filter initDelegate(WebApplicationContext wac) throws ServletException {
//debug得知targetBeanName为:springSecurityFilterChain
String targetBeanName = this.getTargetBeanName();
Assert.state(targetBeanName != null, "No target bean name set");
//debug得知delegate对象为:FilterChainProxy
Filter delegate = (Filter)wac.getBean(targetBeanName, Filter.class);
if (this.isTargetFilterLifecycle()) {
delegate.init(this.getFilterConfig());
}
return delegate;
}
}
第二步debug结果如下:

由此可知,DelegatingFilterProxy通过springSecurityFilterChain这个名称,得到了一个FilterChainProxy过滤器, 最终在第三步执行了这个过滤器。
2-FilterChainProxy
注意代码注释!
public class FilterChainProxy extends GenericFilterBean {
private static final Log logger = LogFactory.getLog(FilterChainProxy.class);
private static final String FILTER_APPLIED =
FilterChainProxy.class.getName().concat(".APPLIED");
private List filterChains;
private FilterChainProxy.FilterChainValidator filterChainValidator;
private HttpFirewall firewall;
//咿!?可以通过一个叫SecurityFilterChain的对象实例化出一个FilterChainProxy对象
//这FilterChainProxy又是何方神圣?会不会是真正的过滤器链对象呢?先留着这个疑问!
public FilterChainProxy(SecurityFilterChain chain) {
this(Arrays.asList(chain));
}
//又是SecurityFilterChain这家伙!嫌疑更大了!
public FilterChainProxy(List filterChains) {
this.filterChainValidator = new FilterChainProxy.NullFilterChainValidator();
this.firewall = new StrictHttpFirewall();
this.filterChains = filterChains;
}
//注:直接从doFilter看
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
boolean clearContext = request.getAttribute(FILTER_APPLIED) == null;
if (clearContext) {
try {
request.setAttribute(FILTER_APPLIED, Boolean.TRUE);
this.doFilterInternal(request, response, chain);
} finally {
SecurityContextHolder.clearContext();
request.removeAttribute(FILTER_APPLIED);
}
} else {
//第一步:具体操作调用下面的doFilterInternal方法了
this.doFilterInternal(request, response, chain);
}
}
private void doFilterInternal(ServletRequest request, ServletResponse response, FilterChain
chain) throws IOException, ServletException {
FirewalledRequest fwRequest =
this.firewall.getFirewalledRequest((HttpServletRequest)request);
HttpServletResponse fwResponse =
this.firewall.getFirewalledResponse((HttpServletResponse)response);
//第二步:封装要执行的过滤器链,那么多过滤器就在这里被封装进去了!
List filters = this.getFilters((HttpServletRequest)fwRequest);
if (filters != null && filters.size() != 0) {
FilterChainProxy.VirtualFilterChain vfc = new
FilterChainProxy.VirtualFilterChain(fwRequest, chain, filters);
//第四步:加载过滤器链
vfc.doFilter(fwRequest, fwResponse);
} else {
if (logger.isDebugEnabled()) {
logger.debug(UrlUtils.buildRequestUrl(fwRequest)

                         + (filters == null ? " has no matching filters" : " has an empty filter list"));
        }
        fwRequest.reset();
        chain.doFilter(fwRequest, fwResponse);
    }
}
private List<Filter> getFilters(HttpServletRequest request) {
    Iterator var2 = this.filterChains.iterator();
    //第三步:封装过滤器链到SecurityFilterChain中!
    SecurityFilterChain chain;
    do {
        if (!var2.hasNext()) {
            return null;
        }
            chain = (SecurityFilterChain)var2.next();
    } while(!chain.matches(request));
    return chain.getFilters();
}

}
第二步debug结果如下图所示,惊不惊喜?十五个过滤器都在这里了!

再看第三步,怀疑这么久!原来这些过滤器还真是都被封装进SecurityFilterChain中了。
3-SecurityFilterChain
最后看SecurityFilterChain,这是个接口,实现类也只有一个,这才是web.xml中配置的过滤器链对象!
//接口
public interface SecurityFilterChain {
boolean matches(HttpServletRequest var1);
List getFilters();
}

//实现类
public final class DefaultSecurityFilterChain implements SecurityFilterChain {

private static final Log logger = LogFactory.getLog(DefaultSecurityFilterChain.class);
private final RequestMatcher requestMatcher;
private final List<Filter> filters;

public DefaultSecurityFilterChain(RequestMatcher requestMatcher,
                                  Filter... filters) {
    this(requestMatcher, Arrays.asList(filters));
}

public DefaultSecurityFilterChain(RequestMatcher requestMatcher, 
                                  List<Filter> filters) {
    logger.info("Creating filter chain: " + requestMatcher + ", " + filters);
    this.requestMatcher = requestMatcher;
    this.filters = new ArrayList(filters);
}

public RequestMatcher getRequestMatcher() {
    return this.requestMatcher;
}

public List<Filter> getFilters() {
    return this.filters;
}

public boolean matches(HttpServletRequest request) {
    return this.requestMatcher.matches(request);
}

public String toString() {
    return "[ " + this.requestMatcher + ", " + this.filters + "]";
}

}
总结:通过此章节,我们对SpringSecurity工作原理有了一定的认识。但理论千万条,功能第一条,探寻底层,是为了更好的使用框架。 那么,言归正传!到底如何使用自己的页面来实现SpringSecurity的认证操作呢?要完成此功能,首先要有一套自己的页面!

相关文章
|
6月前
|
消息中间件 NoSQL Java
SpringCloud
本课程基于黑马程序员2025版SpringCloud实战教学,聚焦高频面试与实际应用,涵盖微服务、RabbitMQ、Redis高级、ElasticSearch等核心内容,结合项目实战与AI模块优化,助力掌握企业级开发技能。资料详尽,尊重原创,侵权必究。
|
6月前
|
存储 算法 BI
xxljob本地运行
本文介绍XXL-JOB分布式任务调度的使用教程。包含源码获取、服务端部署(数据库导入、配置修改、启动访问)、客户端运行与执行器注册,以及调度任务配置和路由策略详解。通过实际操作演示任务创建、参数设置、手动执行与日志查看,帮助开发者快速掌握XXL-JOB核心功能,实现定时任务的可视化管理和高效调度。(238字)
|
6月前
|
Arthas 存储 运维
记Arthas实现一次CPU排查与代码热更新
本文介绍如何使用Arthas排查线上Java应用CPU占用过高问题,结合thread、watch、jad等指令定位阻塞线程与异常代码,实现无需重启服务的热更新修复,并通过profile生成火焰图进行性能分析,提升线上问题排查效率。
|
6月前
|
消息中间件 Java 数据库
异步消息组件MQ高级
本文详解RabbitMQ消息可靠性保障机制,涵盖生产者重试、确认机制(Confirm/Return)、消息持久化及消费可靠性。通过配置重试、回调处理与失败消息表结合定时任务重发,确保消息不丢失,提升系统稳定性。
|
6月前
|
Dubbo Java 应用服务中间件
3.Hessian
Hessian 1协议基于HTTP通信,采用Servlet暴露服务,Dubbo内置Jetty支持。支持与原生Hessian服务互操作,多连接短连接,同步传输,Hessian二进制序列化,适用于参数较大、提供者较多场景,如页面及文件传输。需实现Serializable,限制自定义集合类。配置简单,支持多端口与直连。
|
6月前
|
安全 Java 数据安全/隐私保护
通用权限管理模型
本文介绍了ACL和RBAC两大权限模型。ACL通过用户/角色与权限直接绑定,实现简单但管理复杂;RBAC基于角色授权,支持角色继承、职责分离,更适用于复杂系统。还简述了RBAC0-RBAC3的演进与核心原则,帮助建立权限体系的全局认知。(238字)
|
6月前
|
安全 Java 应用服务中间件
实现权限管理的技术
权限管理技术选型需综合考量。常见方案如Apache Shiro配置简单但安全维护弱;Spring Security功能强大但较复杂;自定义ACL灵活但理解成本高。多数框架基于ACL或RBAC二次封装,应根据项目实际选择最合适的方案。
|
6月前
|
安全 Java 开发工具
工程搭建与验证
本文介绍如何使用阿里云脚手架快速搭建Spring Boot工程,并整合Spring Security。内容涵盖项目初始化、代码导入与验证、引入Web及Security依赖、登录认证测试等。默认Spring Boot版本为3.0.2(需JDK 17),建议选用2.7.6版本以降低环境要求。通过简单步骤即可实现安全访问控制,源码详见GitHub仓库Day01分支。
|
6月前
|
前端开发 安全 Java
自定义认证前端页面
本文介绍Spring Security基础配置:通过定义接口返回欢迎信息,配置SecurityConfig实现权限控制,所有请求需认证,启用表单登录并指定登录页、处理路径及跳转逻辑,禁用CSRF。启动后访问接口自动跳转登录页,输入默认用户信息即可成功访问受保护资源。
|
6月前
|
存储 安全 Java
认证源码分析与自定义后端认证逻辑
本文深入分析Spring Security认证流程,从UsernamePasswordAuthenticationFilter到AuthenticationManager、AuthenticationProvider,最终通过自定义UserDetailsService实现数据库认证。重点解析了认证过程中关键对象的协作机制,如UsernamePasswordAuthenticationToken、SecurityContextHolder等,并详细演示了如何通过实现UserDetailsService接口完成自定义用户加载与权限封装,最后在配置类中注册服务,实现灵活的身份验证。

热门文章

最新文章