2.过滤器链加载原理

简介: 本文深入解析Spring Security底层过滤机制,揭示十五个过滤器如何通过DelegatingFilterProxy和FilterChainProxy自动加载并执行,最终明确SecurityFilterChain才是真正的过滤器链实现。

通过前面十五个过滤器功能的介绍,对于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<SecurityFilterChain> filterChains;
    private FilterChainProxy.FilterChainValidator filterChainValidator;
    private HttpFirewall firewall;
    //咿!?可以通过一个叫SecurityFilterChain的对象实例化出一个FilterChainProxy对象
    //这FilterChainProxy又是何方神圣?会不会是真正的过滤器链对象呢?先留着这个疑问!
    public FilterChainProxy(SecurityFilterChain chain) {
        this(Arrays.asList(chain));
    }
    //又是SecurityFilterChain这家伙!嫌疑更大了!
    public FilterChainProxy(List<SecurityFilterChain> 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<Filter> 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<Filter> 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的认证操作呢?要完成此功能,首先要有一套自己的页面!

目录
相关文章
|
4月前
|
NoSQL Linux Shell
2-MongoDB单机部署
本文介绍了MongoDB在Windows和Linux系统下的安装、配置与启动方法,包括下载地址、版本选择、解压安装、命令行及配置文件启动方式,并详细说明了如何通过Shell和图形化工具Compass连接数据库。同时提供常见问题解决方案及附件中的各环境安装包链接,便于快速部署使用。
127 0
|
4月前
|
缓存 Java Nacos
@RefreshScope热更新原理
本文深入解析Spring Cloud中@RefreshScope注解实现配置热更新的原理。通过分析其组合注解特性,重点剖析@Scope(&quot;refresh&quot;)如何借助动态代理与缓存机制,在配置变更时触发Bean重建,结合Nacos实现配置自动刷新,从而达到无需重启应用即可生效的效果。
158 6
@RefreshScope热更新原理
|
4月前
|
存储 缓存 Java
自动装配机制
本文深入解析SpringBoot自动装配机制,围绕@SpringBootApplication注解展开,剖析其组合注解中的@ComponentScan、@SpringBootConfiguration与@EnableAutoConfiguration核心原理,详解元注解作用及自动配置类如何通过spring.factories实现自动化加载与组件过滤。
113 0
 自动装配机制
|
4月前
|
运维 Devops 开发工具
生产环境缺陷管理
git-poison基于go-git实现分布式bug追踪,解决多分支开发中bug漏修、漏发问题。通过“投毒-解毒-银针”机制,自动化卡点发布流程,降低协同成本,提升发布安全性与效率,已在大型团队落地应用。
66 0
|
4月前
|
Java 测试技术 Linux
生产环境发布管理
本文介绍大型团队中多环境自动化发布流程,涵盖DEV、TEST、PRE、PROD各环境职责,结合CI/CD平台实现分支管理、一键部署,并通过Skywalking等工具高效排查日志,提升发布效率与系统稳定性。
72 0
生产环境发布管理
|
4月前
|
SQL NoSQL 前端开发
大厂如何解决订单幂等问题
本文详解分布式系统中订单接口幂等性设计:通过唯一订单号与数据库主键约束防止重复下单,结合Redis标识与版本号机制解决ABA问题,确保请求重复时数据一致,适用于各类数据库场景。
106 0
大厂如何解决订单幂等问题
|
4月前
|
敏捷开发 Dubbo Java
需求开发人日评估
本文介绍敏捷开发中工时评估的关键方法,以“人日”为单位,结合开发、自测、联调、测试及发布各阶段,提供常见需求如Excel导入导出、单表操作、跨服务调用等的参考人日,并给出并行任务下的调整建议,助力团队科学规划开发周期。
94 0
需求开发人日评估
|
4月前
|
存储 安全 小程序
1.认识OAuth2.0
OAuth2.0是一种开放授权标准,允许第三方应用在用户授权下安全访问资源,无需获取用户账号密码。其核心是通过令牌(token)实现有限授权,广泛用于第三方登录、服务间资源调用等场景,支持授权码、简化、密码和客户端四种模式,兼顾安全性与灵活性。
119 0
 1.认识OAuth2.0
|
4月前
|
SQL 安全 网络协议
常见的网络攻击
恶意软件、网络钓鱼、中间人攻击、DDoS攻击、SQL注入、零日漏洞及DNS隧道是常见网络安全威胁。恶意软件通过漏洞入侵,窃取数据或破坏系统;网络钓鱼伪装可信来源骗取信息;中间人攻击窃听通信;DDoS以海量流量瘫痪服务;SQL注入操控数据库;零日攻击利用未修复漏洞;DNS隧道则隐蔽传输数据,危害网络安全。
174 0
 常见的网络攻击
|
4月前
|
安全 Java 数据安全/隐私保护
2.通用权限管理模型
本文介绍了ACL和RBAC两种常见的权限模型。ACL通过直接为用户或角色授权实现访问控制,简单直观;RBAC则基于角色分配权限,解耦用户与权限关系,更易维护。文中还详解RBAC0-3的演进,涵盖角色继承、职责分离等核心概念,帮助构建系统化权限认知。
138 0
 2.通用权限管理模型

热门文章

最新文章

下一篇
开通oss服务