最近兩天遇到了前端請求後端的跨域問題，傳統的jsonp不能滿足更多的請求方式，因此了解一下cors的方式跨域是必要的。
個人摸索理解，如果需要改正，請指出。多謝。
為什麼需要跨域
瀏覽器的同源策略來起到安全的作用。
需要同協議，同網域名稱/ip，同埠才能直接請求。
這個協議的存在，我們無法正常跨域請求。
跨域請求會先傳送乙個預請求options
預請求成功後需要返回給前端乙個成功的狀態碼
預請求通過，進行真正的請求，實現跨域
前端正常傳送ajax/axios請求
// 設定傳輸內容的型別和編碼
withcredentials:
true
// 指定某個請求應該傳送憑據。允許客戶端攜帶跨域cookie，也需要此配置})
;// 查詢樣例使用者列表 用於測試
export
const
testuser
=(params)
=>
)}後端zuul閘道器處理跨域問題
@component
public
class
tokenfilter
extends
zuulfilter
@override
public
intfilterorder()
@override
public
boolean
shouldfilter()
@override
public object run()
// 第二次請求（非驗證，eg：get請求不會進到上面的if） 會走到這裡往下進行
// 不需要token認證
ctx.
setsendzuulresponse
(true);
//對請求進行路由
}}
第二個正常請求：
請求到的資料
上面是可以成功訪問的**。
當我們注釋掉if 讓options 直接請求路由，會發生什麼？
會出現下面的提示，大概意思就是 options沒有返回 乙個成功的狀態碼，但是上面**確實有
這是卡我一下午一直很疑惑的地方，而且zuul也沒有報錯，除錯發現只有乙個options請求，沒有收到get請求，可能就是他繼續路由出現了異常，沒有返回狀態碼，即使調換**順序也還是下面的錯誤。
下面這個錯誤就是後端什麼都沒有配置，出現的錯誤，大概意思就是
請求的資源上不存在「access-control-allow-origin」標頭。
就是這些沒有配置，後端不認你的遠端請求位址
那今天就到這裡吧，如果有問題，在繼續研究完善。
跨域問題的解決方案
首先了解下瀏覽器的同源策略 同源策略 sop same origin policy 是一種約定，由netscape公司1995年引入瀏覽器，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，瀏覽器很容易受到xss csfr等攻擊。所謂同源是指 協議 網域名稱 埠 三者相同，三者有乙個不相同那麼...
跨域解決方案
因為瀏覽器出於安全考慮，有同源策略。也就是說，如果協議 網域名稱或者埠有乙個不同就是跨域，ajax 請求會失敗。那麼是出於什麼安全考慮才會引入這種機制呢？其實主要是用來防止 csrf 攻擊的。簡單點說，csrf 攻擊是利用使用者的登入態發起惡意請求。也就是說，沒有同源策略的情況下，a 可以被任意其他...
跨域解決方案
瀏覽器端的同源策略 如果兩個頁面的協議,埠和網域名稱中的其中任意乙個不相同,它們就是不同源的,瀏覽器會限制他們之間的資源互動 跨域 跨域的安全限制只針對瀏覽器,伺服器是沒有跨域的安全限制的 原理 由於伺服器沒有跨域限制，所以在需要跨域訪問時，在中間設定乙個中間層 舉例 192.168.10.1 80...