后端通過CorsRegistry配置了全局跨域，但是前端仍然報(bào)CORS跨域錯(cuò)誤
-
問題背景
在實(shí)現(xiàn)登錄功能時(shí)，我先是通過CorsRegistry配置了全局跨域，然后配置了一個(gè)登錄攔截器后前端就報(bào)錯(cuò)
CORS跨域錯(cuò)誤 -
問題原因
-
前置知識(shí)
首先我們來了解一下什么是跨域錯(cuò)誤，跨域錯(cuò)誤（Cross-Origin Error）是在Web開發(fā)中常見的錯(cuò)誤之一，它發(fā)生在瀏覽器執(zhí)行跨源請(qǐng)求（從一個(gè)源訪問另一個(gè)源）時(shí)。同源策略（Same-Origin Policy）是瀏覽器的安全機(jī)制，它限制了通過腳本在不同源之間進(jìn)行跨域通信。"源"是由協(xié)議、主機(jī)名和端口號(hào)組成的標(biāo)識(shí)符。如果兩個(gè)頁面的協(xié)議、主機(jī)名和端口號(hào)完全相同，則它們被視為同源。同源策略的存在是為了保障網(wǎng)站安全、防止跨站腳本攻擊。
-
原因分析
在前后端分離的項(xiàng)目中，很容易出現(xiàn)跨域錯(cuò)誤，因?yàn)榍岸撕秃蠖说亩丝谔?hào)、主機(jī)名一般都不相同，此時(shí)前端能夠發(fā)送請(qǐng)求給后端，但是由于同源策略的存在，會(huì)直接被瀏覽器給攔截。從而出現(xiàn)CORS錯(cuò)誤。
瀏覽器如何判斷當(dāng)前是否跨域呢？瀏覽器會(huì)在發(fā)送真實(shí)請(qǐng)求之前先發(fā)送一個(gè)OPTIONS請(qǐng)求，這個(gè)請(qǐng)求相當(dāng)于一個(gè)探子，如果發(fā)現(xiàn)目標(biāo)路徑可達(dá)并且端口、主機(jī)一致就會(huì)直接通過，如果不一致瀏覽器就會(huì)直接攔截前端的請(qǐng)求，導(dǎo)致后續(xù)的真實(shí)請(qǐng)求（比如GET、POST、PUT、DELETE）無法發(fā)送到后端。
所以錯(cuò)誤的跟本原因在于OPTIONS，由于我配置了登錄攔截器，對(duì)于放行請(qǐng)求，不會(huì)有什么問題，但是對(duì)于沒有放行的請(qǐng)求，會(huì)直接攔截OPTIONS請(qǐng)求，OPTIONS請(qǐng)求是一個(gè)探測請(qǐng)求，內(nèi)部并不會(huì)攜帶token，所以就直接導(dǎo)致OTIONS請(qǐng)求被攔截，這樣就會(huì)讓瀏覽器覺得請(qǐng)求不可達(dá)，直接在前端報(bào)CORS error
-
-
問題解決
解決跨域問題的方法有很多，我了解的有配置代理（配置代理的方式也有很多，比如Nginx、大部分前端腳手架也有自帶的Prox模塊用于配置代理）、使用JSONP的
<script>標(biāo)簽也可以配置跨域，我一般都是直接在后端配置跨域的，可以使用**CorsRegistry對(duì)象進(jìn)行全局配置，也可以使用@CrossOrigin注解**進(jìn)行單個(gè)請(qǐng)求配置，而當(dāng)前項(xiàng)目中我所使用的是 CorsRegistry 對(duì)象進(jìn)行全局配置。-
方案一：直接使用代理，比如Nginx、前端腳手架自帶的代理（可行，但我沒有使用）
-
方案二：在后端的登錄攔截器中放行所有的
OPTIONS請(qǐng)求（采用并成功解決）
-
可以看到配置后，重啟后端項(xiàng)目，然后就沒有出現(xiàn) CORS error錯(cuò)誤了
文章來源：http://www.zghlxwxcb.cn/news/detail-721922.html
參考文章文章來源地址http://www.zghlxwxcb.cn/news/detail-721922.html
- SpringBoot加了攔截器后出現(xiàn)的跨域問題解析
到了這里，關(guān)于后端通過CorsRegistry對(duì)象配置了全局跨域，但是前端仍然報(bào)CORS跨域錯(cuò)誤的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
