深入理解 FilterChainProxy【原始碼篇】

昨天有小夥伴加鬆哥微信，說他把鬆哥的 Spring Security 系列擼完了。。

but 鬆哥這個系列還沒發完呢，在我的計劃中，Spring Security 系列目前應該能更新一半，還剩一半，雖然有的小夥伴可能覺得好像已經沒啥了，其實還有很多東西。。。

鬆哥最近也是特別忙，Security 更新慢下來了，但是秉持前面說的，要學就成系列的學，要學就學透徹，這個系列我還會繼續更下去。

今天我們就來聊一聊 Spring Security 系列中的 FilterChainProxy。

這是一個非常重要的代理物件。

1. FilterChainProxy

我們先來回顧一下前面文章講的：

在一個 Web 專案中，請求流程大概如下圖所示：

請求從客戶端發起（例如瀏覽器），然後穿過層層 Filter，最終來到 Servlet 上，被 Servlet 所處理。

上圖中的 Filter 我們可以稱之為 Web Filter，Spring Security 中的 Filter 我們可以稱之為 Security Filter，它們之間的關係如下圖：

可以看到，Spring Security Filter 並不是直接嵌入到 Web Filter 中的，而是通過 FilterChainProxy 來統一管理 Spring Security Filter，FilterChainProxy 本身則通過 Spring 提供的 DelegatingFilterProxy 代理過濾器嵌入到 Web Filter 之中。

DelegatingFilterProxy 很多小夥伴應該比較熟悉，在 Spring 中手工整合 Spring Session、Shiro 等工具時都離不開它，現在用了 Spring Boot，很多事情 Spring Boot 幫我們做了，所以有時候會感覺 DelegatingFilterProxy 的存在感有所降低，實際上它一直都在。

FilterChainProxy 中可以存在多個過濾器鏈，如下圖：

可以看到，當請求到達 FilterChainProxy 之後，FilterChainProxy 會根據請求的路徑，將請求轉發到不同的 Spring Security Filters 上面去，不同的 Spring Security Filters 對應了不同的過濾器，也就是不同的請求將經過不同的過濾器。

這是 FilterChainProxy 的一個大致功能，今天我們就從原始碼上理解 FilterChainProxy 中這些功能到底是怎麼實現的。

2. 原始碼分析

先把 FilterChainProxy 原始碼亮出來，這個原始碼比較上，我們一部分一部分來，先從它宣告的全域性屬性上開始：

private final static String FILTER_APPLIED = FilterChainProxy.class.getName().concat(
        ".APPLIED");
private List<SecurityFilterChain> filterChains;
private FilterChainValidator filterChainValidator = new NullFilterChainValidator();
private HttpFirewall firewall = new StrictHttpFirewall();

FILTER_APPLIED 變數是一個標記，用來標記過濾器是否已經執行過了。這個標記在 Spring Security 中很常見，鬆哥這裡就不多說了。
filterChains 是過濾器鏈，注意，這個是過濾器鏈，而不是一個個的過濾器，在【Spring Security 竟然可以同時存在多個過濾器鏈？】一文中，鬆哥教過大家如何配置多個過濾器鏈，配置的多個過濾器鏈就儲存在 filterChains 變數中，也就是，如果你有一個過濾器鏈，這個集合中就儲存一條記錄，你有兩個過濾器鏈，這個記錄中就儲存兩條記錄，每一條記錄又對應了過濾器鏈中的一個個過濾器。
filterChainValidator 是 FilterChainProxy 配置完成後的校驗方法，預設使用的 NullFilterChainValidator 實際上對應了一個空方法，也就是不做任何校驗。
firewall 我們在前面的文章中也介紹過(Spring Security 自帶防火牆！你都不知道自己的系統有多安全！)，這裡就不再贅述。

接下來我們來看一個過濾器中最重要的 doFilter 方法：

@Override
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);
            doFilterInternal(request, response, chain);
        }
        finally {
            SecurityContextHolder.clearContext();
            request.removeAttribute(FILTER_APPLIED);
        }
    }
    else {
        doFilterInternal(request, response, chain);
    }
}

在 doFilter 方法中，正常來說，clearContext 引數每次都是 true，於是每次都先給 request 標記上 FILTER_APPLIED 屬性，然後執行 doFilterInternal 方法去走過濾器，執行完畢後，最後在 finally 程式碼塊中清除 SecurityContextHolder 中儲存的使用者資訊，同時移除 request 中的標記。

按著這個順序，我們來看 doFilterInternal 方法：

private void doFilterInternal(ServletRequest request, ServletResponse response,
        FilterChain chain) throws IOException, ServletException {
    FirewalledRequest fwRequest = firewall
            .getFirewalledRequest((HttpServletRequest) request);
    HttpServletResponse fwResponse = firewall
            .getFirewalledResponse((HttpServletResponse) response);
    List<Filter> filters = getFilters(fwRequest);
    if (filters == null || filters.size() == 0) {
        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);
        return;
    }
    VirtualFilterChain vfc = new VirtualFilterChain(fwRequest, chain, filters);
    vfc.doFilter(fwRequest, fwResponse);
}
private List<Filter> getFilters(HttpServletRequest request) {
    for (SecurityFilterChain chain : filterChains) {
        if (chain.matches(request)) {
            return chain.getFilters();
        }
    }
    return null;
}

doFilterInternal 方法就比較重要了：

首先將請求封裝為一個 FirewalledRequest 物件，在這個封裝的過程中，也會判斷請求是否合法。具體參考鬆哥之前的 Spring Security 自帶防火牆！你都不知道自己的系統有多安全！一文。
對響應進行封裝。
呼叫 getFilters 方法找到過濾器鏈。該方法就是根據當前的請求，從 filterChains 中找到對應的過濾器鏈，然後由該過濾器鏈去處理請求，具體可以參考 Spring Security 竟然可以同時存在多個過濾器鏈？一文。
如果找出來的 filters 為 null，或者集合中沒有元素，那就是說明當前請求不需要經過過濾器。直接執行 chain.doFilter ，這個就又回到原生過濾器中去了。那麼什麼時候會發生這種情況呢？那就是針對專案中的靜態資源，如果我們配置了資源放行，如 web.ignoring().antMatchers("/hello");，那麼當你請求 /hello 介面時就會走到這裡來，也就是說這個不經過 Spring Security Filter。這個鬆哥之前也專門寫文章介紹過：Spring Security 兩種資源放行策略，千萬別用錯了！。
如果查詢到的 filters 中是有值的，那麼這個 filters 集合中存放的就是我們要經過的過濾器鏈了。此時它會構造出一個虛擬的過濾器鏈 VirtualFilterChain 出來，並執行其中的 doFilter 方法。

那麼接下來我們就來看看 VirtualFilterChain：

private static class VirtualFilterChain implements FilterChain {
    private final FilterChain originalChain;
    private final List<Filter> additionalFilters;
    private final FirewalledRequest firewalledRequest;
    private final int size;
    private int currentPosition = 0;
    private VirtualFilterChain(FirewalledRequest firewalledRequest,
            FilterChain chain, List<Filter> additionalFilters) {
        this.originalChain = chain;
        this.additionalFilters = additionalFilters;
        this.size = additionalFilters.size();
        this.firewalledRequest = firewalledRequest;
    }
    @Override
    public void doFilter(ServletRequest request, ServletResponse response)
            throws IOException, ServletException {
        if (currentPosition == size) {
            if (logger.isDebugEnabled()) {
                logger.debug(UrlUtils.buildRequestUrl(firewalledRequest)
                        + " reached end of additional filter chain; proceeding with original chain");
            }
            // Deactivate path stripping as we exit the security filter chain
            this.firewalledRequest.reset();
            originalChain.doFilter(request, response);
        }
        else {
            currentPosition++;
            Filter nextFilter = additionalFilters.get(currentPosition - 1);
            if (logger.isDebugEnabled()) {
                logger.debug(UrlUtils.buildRequestUrl(firewalledRequest)
                        + " at position " + currentPosition + " of " + size
                        + " in additional filter chain; firing Filter: '"
                        + nextFilter.getClass().getSimpleName() + "'");
            }
            nextFilter.doFilter(request, response, this);
        }
    }
}

VirtualFilterChain 類中首先宣告瞭 5 個全域性屬性，originalChain 表示原生的過濾器鏈，也就是 Web Filter；additionalFilters 表示 Spring Security 中的過濾器鏈；firewalledRequest 表示當前請求；size 表示過濾器鏈中過濾器的個數；currentPosition 則是過濾器鏈遍歷時候的下標。
doFilter 方法就是 Spring Security 中過濾器挨個執行的過程，如果 currentPosition == size，表示過濾器鏈已經執行完畢，此時通過呼叫 originalChain.doFilter 進入到原生過濾鏈方法中，同時也退出了 Spring Security 過濾器鏈。否則就從 additionalFilters 取出 Spring Security 過濾器鏈中的一個個過濾器，挨個呼叫 doFilter 方法。

最後，FilterChainProxy 中還定義了 FilterChainValidator 介面及其實現：

public interface FilterChainValidator {
    void validate(FilterChainProxy filterChainProxy);
}
private static class NullFilterChainValidator implements FilterChainValidator {
    @Override
    public void validate(FilterChainProxy filterChainProxy) {
    }
}

實際上這個實現並未做任何事情。

這就是 FilterChainProxy 中的整個邏輯。

3. 小結

其實本文中的很多知識點鬆哥在之前的文章中都和大家介紹過，例如配置多個過濾器鏈、StrictHttpFireWall、兩種資源放行方式等等，但是之前主要是和大家分享用法，沒有去細究他的原理，今天的文章，我們通過原始碼把這個問題捋了一遍，相信大家對於這些功能細節也更清晰了。

好啦，感興趣的小夥伴記得點個在看鼓勵下鬆哥哦～

深入理解 FilterChainProxy【原始碼篇】

1. FilterChainProxy

2. 原始碼分析

3. 小結

相關文章