1. 背景分析

眾所周知CorsFilter是Spring提供的跨域過濾器，我們可能會做以下的配置，基本上就是允許任何跨域請求

@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        //允許所有域名進(jìn)行跨域調(diào)用
        config.addAllowedOriginPattern("*");
        //允許跨越發(fā)送cookie
        config.setAllowCredentials(true);
        //放行全部原始頭信息
        config.addAllowedHeader("*");
        //允許所有請求方法跨域調(diào)用
        config.addAllowedMethod("*");
        //跨域允許時(shí)間，單位：秒
        config.setMaxAge(60 * 60L);
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }
}

我們的系統(tǒng)主要是SpringBoot+SpringSecurity構(gòu)成的，我利用Spring的CorsFilter做跨域操作也沒問題吧

但就是在這種簡單的情況下前端還是爆出了跨域情況

這就頭大了呀，畢竟網(wǎng)上的教程和我的經(jīng)驗(yàn)分析都覺得是可以的

2. 問題分析

這個(gè)時(shí)候就沒辦法了，只能本地Debug + 分析源碼，看看問題所在地

然后我是利用Apifox里面保存的請求實(shí)例，然后復(fù)制一份(這里面有系統(tǒng)的認(rèn)證參數(shù))，請求方式改為了OPTIAN了，然后其他雜七雜八的請求頭也從前端中復(fù)制到新的請求實(shí)例中了

然后啟動(dòng)項(xiàng)目，打好斷點(diǎn)

最終發(fā)現(xiàn)進(jìn)入了CorsFilter的doFilterInternal方法，并且判斷成功，確實(shí)是一個(gè)OPTIAON, 響應(yīng)頭也已經(jīng)填充了對應(yīng)的響應(yīng)頭，ApiFox也提示請求正常

這就離譜了，dev環(huán)境不可以，local環(huán)境就可以了，這個(gè)時(shí)候我決定不偷懶了，新建一個(gè)請求實(shí)例，完全照搬前端發(fā)起的請求

這個(gè)時(shí)候問題就稍微浮出水面了，我發(fā)現(xiàn)CorsFilter都沒進(jìn)去，Apifox就已經(jīng)提示了跨域了

于是我繼續(xù)分析向上的流程，大家看下面的這個(gè)圖，這是注冊到Tomcat中的過濾器組成的過濾器鏈

先看前三個(gè)過濾器：

• OrderedCharacterEncodingFilter：確認(rèn)本次請求的編碼格式
• OrderedCharacterEncodingFilter：為PUT、PATCH、DELETE這樣的請求方式，將請求體轉(zhuǎn)為鍵值對形式，然后通過 getParameter 讀取
• OrderedRequestContextFilter：用于初始化 LocaleContextHolder 和 RequestContextHolder 的過濾器

然后我們再看后面的springSecurityFilterChain和corsFilter,注意這里是springSecurityFilterChain在前，也就是會先執(zhí)行

我最新的這一次跨域請求是沒有攜帶認(rèn)證參數(shù)的，也就是說會被SpringSecurity的ExceptionTranslationFilter處理訪問被拒絕異常，也就不會走后面的corsFilter，也就不會寫入響應(yīng)頭的相關(guān)參數(shù)了

3. 解決辦法

3.1 SpringSecurity的角度

問題分析到這其實(shí)解決思路就很簡單了，要么我們改用SpringSecurity提供的跨域支持，就像下面這樣

3.2 SpringBoot的角度

要么我們就改變注冊到Tomcat的CorsFilter的執(zhí)行順序，我當(dāng)時(shí)也是這樣處理的，看下圖我介紹的三個(gè)過濾器均在 springSecurityFilterChain之前執(zhí)行，并且他們的順序是保持一致的，也就是SpringBoot一定做了排序的

我們可以先看這三個(gè)過濾器的共同點(diǎn)：他們都同時(shí)實(shí)現(xiàn)了OrderedFilter接口，并且重寫getOrder()方法

在這種情況下，我就自己寫了一個(gè)CorsFilter, 并實(shí)現(xiàn)了OrderedFilter

然后我們就可以發(fā)現(xiàn)過濾器的順序發(fā)生了變化

前端也正常的發(fā)起了跨域請求，業(yè)務(wù)流程也可以繼續(xù)跑了

4. 總結(jié)

總結(jié)：

• 其實(shí)跨域問題很好解決，本質(zhì)上就是后端要設(shè)置對應(yīng)的響應(yīng)頭
• 我這里出現(xiàn)問題還是因?yàn)樽约和祽辛耍苯訌?fù)制以前的請求實(shí)例發(fā)起OPTION請求
• 還有就是沒想起來SpringBoot和SpringSecurtiy中處理跨域會有一個(gè)先后順序(沖突)的問題才導(dǎo)致的
• 當(dāng)然Spring中處理跨域其實(shí)不只CorsFilter這一種方式，還可以通過RequestMappingHandlerMapping完成，就在下面的地方，這個(gè)后續(xù)在介紹

以上就是Spring的CorsFilter會失效的原因及解決方法的詳細(xì)內(nèi)容，更多關(guān)于Spring CorsFilter失效的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論