快捷導(dǎo)航

Spring的CorsFilter會失效的原因及解決方法

更新時間：2023年09月28日 11:11:04 作者：帆_布

眾所周知CorsFilter是Spring提供的跨域過濾器,我們可能會做以下的配置,基本上就是允許任何跨域請求,我利用Spring的CorsFilter做跨域操作但是出現(xiàn)報錯,接下來小編就給大家介紹一Spring的CorsFilter會失效的原因及解決方法,需要的朋友可以參考下

1. 背景分析

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

@Configuration
public class CorsConfig {
    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration config = new CorsConfiguration();
        //允許所有域名進行跨域調(diào)用
        config.addAllowedOriginPattern("*");
        //允許跨越發(fā)送cookie
        config.setAllowCredentials(true);
        //放行全部原始頭信息
        config.addAllowedHeader("*");
        //允許所有請求方法跨域調(diào)用
        config.addAllowedMethod("*");
        //跨域允許時間，單位：秒
        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)驗分析都覺得是可以的

2. 問題分析

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

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

然后啟動項目，打好斷點

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

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

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

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

先看前三個過濾器：

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的角度

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

3.2 SpringBoot的角度

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

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

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

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

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

4. 總結(jié)

總結(jié)：

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