)
遇到過“跨域訪問被拒絕請檢查瀏覽器配置!”這種提示的人大概率會經(jīng)歷三個階段先是懷疑瀏覽器壞了然后懷疑后端代碼有問題最后查了一圈發(fā)現(xiàn)是既不完全是瀏覽器也不是后端的“機制”在起作用?？缬騿栴}就是這么擰巴它明明不是代碼邏輯錯誤卻能讓前后端聯(lián)調(diào)陷入僵局而且?guī)缀趺總€做Web開發(fā)的人都會遇到。更魔幻的是你搜到的解決方案往往只有一句“加個請求頭”或者“開個代理”卻沒人告訴你為什么瀏覽器要攔你、后端怎么配才是對的、代理轉(zhuǎn)發(fā)之后請求到底從哪來。我在經(jīng)歷過php后端配JSONP、vue開發(fā)代理、django打包部署后nginx調(diào)CORS、還有谷歌瀏覽器跨域登錄帶Cookie這些場景之后才把跨域這攤事情徹底理順。這篇文章就照著我的真實踩坑路徑來寫從同源策略的底層邏輯講起把JSONP、CORS、代理轉(zhuǎn)發(fā)這些方案掰開揉碎最后再分享一個讓我很受啟發(fā)的視角——網(wǎng)絡(luò)里的“跨域”和芯片設(shè)計里的“跨時鐘域”CDC本質(zhì)上是同一類問題想通了這一點很多配置就不再是死記硬背了。1. 同源策略到底在保護什么從一次真實報錯講起1.1 那個“請檢查瀏覽器配置”的誤導(dǎo)性提示先還原一下我遇到過的一個經(jīng)典場面。前端頁面跑在http://localhost:8080后端接口在http://localhost:8000頁面里用fetch發(fā)起請求控制臺報錯信息被某些框架包裝成了“跨域訪問被拒絕請檢查瀏覽器配置!”。我當(dāng)時第一反應(yīng)是Chrome的安全設(shè)置出問題了畢竟提示文字直指瀏覽器配置結(jié)果翻遍設(shè)置也沒找出個開關(guān)來。后來才知道這個提示的準(zhǔn)確意思是“瀏覽器攔截了來自http://localhost:8080對http://localhost:8000的請求”而攔截的依據(jù)就是同源策略。報錯信息之所以寫得像“瀏覽器配置”問題是因為很多封裝庫為了照顧業(yè)務(wù)開發(fā)者的情緒把錯誤信息人性化處理了但恰恰是這個處理讓排查方向跑偏。真實情況是瀏覽器沒有配置錯后端接口也沒有宕機只是這兩個地址的“源”不同。1.2 同源的三要素協(xié)議、域名、端口“源”這個概念簡單說就是協(xié)議加域名加端口三位一體任何一個不一樣就算跨域。頁面地址請求地址是否同源原因http://example.com/pagehttp://example.com/api同源協(xié)議域名端口全一致http://example.comhttps://example.com跨域協(xié)議不同http://example.comhttp://api.example.com跨域域名不同http://example.com:8080http://example.com跨域端口不同很多人在自己機器上聯(lián)調(diào)沒事一上測試環(huán)境就開始跨域多半就是端口或者域名變了。比如后端從localhost:8000換成了內(nèi)網(wǎng)IP加端口前端代碼里的請求地址沒跟著改或者反向代理的路徑?jīng)]對上。我之前幫人排查過一個vue項目開發(fā)時代理配得好好的打包部署到nginx后就瘋狂報跨域最后發(fā)現(xiàn)是nginx監(jiān)聽的是127.0.0.1:80而前端頁面用IP訪問也屬于源不一致。1.3 瀏覽器為什么要“多管閑事”如果瀏覽器不做同源策略會發(fā)生什么想象你登錄了銀行系統(tǒng)保持會話狀態(tài)然后打開另一個惡意網(wǎng)站。惡意網(wǎng)站的腳本如果可以直接請求銀行接口就能以你的身份轉(zhuǎn)賬、改密碼。同源策略就是一道隔離墻讓A網(wǎng)站里的腳本只能訪問A網(wǎng)站的數(shù)據(jù)碰不到B網(wǎng)站。這里有個關(guān)鍵點同源策略是瀏覽器的行為不是HTTP協(xié)議本身的約束。服務(wù)器之間發(fā)起請求完全不受同源策略限制。這意味著php后端訪問python后端、curl命令直連接口都不會有跨域問題?？缬蜻@道坎只存在于瀏覽器環(huán)境里是瀏覽器主動幫你擋住了“跨源”的頁面發(fā)起“跨源”的請求。所以CORS的解決方案也很有意思——不是讓瀏覽器放開限制而是讓目標(biāo)服務(wù)器明確告訴瀏覽器“這個源我可以信任”瀏覽器收到這個聲明后才放行。另外還要補充一點同源策略并沒有一竿子打死所有跨源資源script、img、link這些標(biāo)簽天然允許跨域加載這也是JSONP方案能存在的前提。明白了這一點你就能理解為什么JSONP只能用GET請求——它本質(zhì)上是動態(tài)創(chuàng)建一個script標(biāo)簽來加載數(shù)據(jù)script標(biāo)簽不是XMLHttpRequest自然只能發(fā)GET。2. 繞過跨域的幾種姿勢與它們的使用邊界2.1 JSONP老牌方案的原理與php側(cè)配合JSONP的思路很直白既然script標(biāo)簽跨域加載不受限制那就把接口數(shù)據(jù)包裝成一段JavaScript代碼用script標(biāo)簽加載回來。前端定義好回調(diào)函數(shù)后端返回callback({...})的形式script加載完就自動執(zhí)行。我在php項目里配合過一個JSONP接口后端代碼大致是這樣?php $callback $_GET[callback] ?? ; $data [code 0, data [name test]]; if ($callback) { header(Content-Type: application/javascript); echo $callback . ( . json_encode($data) . ); } else { header(Content-Type: application/json); echo json_encode($data); }前端調(diào)用function handleData(res) { console.log(res); } const script document.createElement(script); script.src http://api.example.com/user?callbackhandleData; document.body.appendChild(script);這種方式在配合不好的情況下會讓人抓狂因為它有幾個硬傷只能GET、沒有錯誤處理機制接口掛了頁面直接報錯你很難拿到錯誤碼、而且容易造成回調(diào)函數(shù)全局污染。所以現(xiàn)在JSONP基本只在維護老項目或者對接第三方老接口時才會用到。如果你在2020年之后的新項目里看到有人還在主張用JSONP那基本可以判斷對方是沒怎么接觸過CORS的老選手。2.2 CORS當(dāng)前的主流方案后端跨域配置的完整鏈路CORS的全稱是跨域資源共享它和JSONP最大的區(qū)別在于它不是繞過同源策略而是讓服務(wù)器顯式聲明允許哪些源訪問。瀏覽器發(fā)現(xiàn)請求是跨域的會先看服務(wù)器的響應(yīng)頭里有沒有Access-Control-Allow-Origin如果有并且包含了當(dāng)前源就放行否則就攔截并報錯。后端要做的是在響應(yīng)里添加跨域響應(yīng)頭。我以php和django為例寫下最基礎(chǔ)的配置。php接口加頭header(Access-Control-Allow-Origin: http://localhost:8080); header(Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization);django里可以寫個中間件class CorsMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): response self.get_response(request) response[Access-Control-Allow-Origin] http://localhost:8080 response[Access-Control-Allow-Methods] GET, POST, PUT, DELETE, OPTIONS response[Access-Control-Allow-Headers] Content-Type, Authorization return response配置CORS時有個很容易踩的坑后面第3節(jié)我會單獨展開講通配符和credentials的沖突問題。這里先記住一個核心原則Access-Control-Allow-Origin不要隨便寫*尤其是涉及登錄狀態(tài)時要更謹慎。2.3 代理轉(zhuǎn)發(fā)開發(fā)環(huán)境的最優(yōu)解以及一個困擾很多人的問題如果你用的是vue-cli或者vite開發(fā)環(huán)境配跨域代理是效率最高的方式。原理很簡單瀏覽器只跟同源的開發(fā)服務(wù)器通信開發(fā)服務(wù)器收到請求后再轉(zhuǎn)發(fā)給真實后端轉(zhuǎn)發(fā)過程發(fā)生在服務(wù)端不受瀏覽器同源策略限制。vue.config.js里的典型配置module.exports { devServer: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true, pathRewrite: { ^/api: } } } } };不過配置完代理之后很多人會遇到一個困惑我在后端接口里想要拿到用戶的真實請求地址結(jié)果發(fā)現(xiàn)所有請求的地址都變成了http://localhost:8080后端拿不到客戶端真實IP。這個問題的根源在于代理服務(wù)器默認會替換掉Host頭后端的請求日志里看到的統(tǒng)一是代理服務(wù)器的地址。解決辦法是在代理配置里通過headers設(shè)置Host或者在nginx層用proxy_set_header Host $host;把真實的Host信息傳給后端。簡單說代理只是幫你把請求轉(zhuǎn)發(fā)出去但如果你需要完整的真實請求鏈路信息必須在代理層顯式傳遞X-Forwarded-For、Host這些頭。2.4 其他方案postMessage與document.domain等postMessage適合iframe跨域通信的場景比如頁面里嵌入了其他域名的iframe雙方通過postMessage和message事件來交換數(shù)據(jù)。這個方法比較冷門但處理跨域iframe的交互時幾乎是唯一選擇。document.domain只能在同一個主域名下的子域之間使用比如a.example.com和b.example.com可以把domain改為example.com實現(xiàn)通信但這會把子域的隔離性破壞掉現(xiàn)在用的人很少。WebSocket天然支持跨域握手階段由服務(wù)器校驗Origin業(yè)務(wù)里如果長連接需求多可以直接走這個不用糾結(jié)CORS。這些方案我給出的排序是新項目一律上CORS開發(fā)環(huán)境用代理提速遇到iframe通信再去看postMessageJSONP只用于老接口兼容。3. CORS配置錯誤排查從“failed to load”到“預(yù)檢請求”的完整鏈路3.1 Access-Control-Allow-Origin的瘋狂踩坑通配符與credentials有一次我在做一個帶登錄態(tài)的跨域請求前端設(shè)置了withCredentials: true后端也很老實地配了Access-Control-Allow-Origin: *但請求還是報錯。錯誤提示是“The value of the Access-Control-Allow-Origin header in the response must not be the wildcard * when the requests credentials mode is include”。這個坑特別隱蔽因為單看響應(yīng)頭Access-Control-Allow-Origin: *是合法的但一旦請求帶了Cookie瀏覽器就不允許通配符了。原理在于如果允許*加憑據(jù)任何網(wǎng)站都可以拿著你的Cookie去請求這個接口不需要服務(wù)器顯式信任任何源這等于把同源策略的隔離墻拆了。正確的做法是指定具體的源比如Access-Control-Allow-Origin: http://localhost:8080 Access-Control-Allow-Credentials: true而且要特別注意的是這兩個頭必須配合使用只加Access-Control-Allow-Credentials不加具體的Origin也不行。我在一個項目里看到后端處理跨域的邏輯是直接反射請求頭里的Origin再返回這樣乍一看能通配所有域名但安全隱患極大——因為你相當(dāng)于對所有源都放行了同源策略形同虛設(shè)。正確做法是維護一個白名單代碼里判斷請求頭里Origin是否在白名單中命中才返回對應(yīng)的頭。3.2 預(yù)檢請求OPTIONS瀏覽器的小心試探很多人第一次看到OPTIONS請求時會蒙圈我明明發(fā)的POST為什么瀏覽器先發(fā)了個OPTIONS這就是CORS的預(yù)檢機制。當(dāng)你的請求滿足一定條件時比如用了Content-Type: application/json、自定義請求頭、或者非GET/HEAD/POST方法瀏覽器會先發(fā)一個OPTIONS請求問服務(wù)器我這個跨域請求你允許嗎允許的話我再發(fā)真正的請求。服務(wù)器處理邏輯里如果沒覆蓋OPTIONS方法預(yù)檢請求就會得到非2xx的響應(yīng)瀏覽器直接阻止真實請求發(fā)出。我在django里給接口加裝飾器時遇到過一種情況GET接口正常POST接口死活跨域失敗后來發(fā)現(xiàn)是POST請求帶JSON體觸發(fā)了預(yù)檢而后端路由沒處理OPTIONS。解決方式一般有兩種要么在后端對OPTIONS統(tǒng)一放行要么用第三方庫的CORS中間件來接管。flask里直接用flask-corsdjango用django-cors-headers比自己手寫響應(yīng)頭省心很多因為這類庫已經(jīng)把預(yù)檢、鑒權(quán)、白名單這些邊界情況都處理好了。用庫并不是偷懶這些邊界情況自己重寫一遍成本極高。3.3 vuedjango打包部署后無法跨域nginx層的關(guān)鍵配置開發(fā)環(huán)境下vue的代理配置得好好的一打包部署就各種問題首先是前端請求的地址變了。開發(fā)時你請求的是/api代理會幫你轉(zhuǎn)發(fā)但打包后如果只把靜態(tài)文件丟到nginx沒有對應(yīng)的/api轉(zhuǎn)發(fā)規(guī)則請求就會打到nginx自己身上然后404或者觸發(fā)跨域。我常用的nginx配置是這樣的server { listen 80; server_name example.com; # 前端靜態(tài)文件 location / { root /var/www/frontend; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這種情況下根本不需要CORS因為瀏覽器訪問的源是example.com它請求的/api也指向example.com兩者同源。這才是生產(chǎn)環(huán)境最推薦的部署方式前端和后端共用一個域名通過路徑區(qū)分徹底繞開跨域。如果你非要前后端分開部署比如前端在cdn.example.com后端在api.example.com那就在nginx層給后端加上CORS頭location / { add_header Access-Control-Allow-Origin https://cdn.example.com always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS, PUT, DELETE always; add_header Access-Control-Allow-Headers Content-Type, Authorization always; add_header Access-Control-Allow-Credentials true always; if ($request_method OPTIONS) { return 204; } }注意add_header后面的always參數(shù)如果沒有它某些場景下比如響應(yīng)碼非200頭可能不會加進去排查時會很困惑。3.4 一個完整的跨域問題排查鏈路我把自己常用的排查順序整理成了一張清單遇到跨域問題按這個順序查基本十幾分鐘內(nèi)能定位打開瀏覽器控制臺Network看請求到底發(fā)出去了沒有。如果請求是紅色的failed點開Response Headers看有沒有Access-Control-Allow-Origin。如果沒有這個頭說明是后端沒配置CORS問題在服務(wù)端去查后端中間件或nginx配置。如果有這個頭但值不是當(dāng)前頁面的源說明白名單沒匹配上去查Origin配置。如果請求帶上Cookie還報錯查Access-Control-Allow-Credentials是否為true且Access-Control-Allow-Origin是否為具體源而非*。如果看到兩次請求一次OPTIONS一次POST查OPTIONS請求的響應(yīng)碼非2xx就說明預(yù)檢沒過。這個方法幫我解決過不下幾十個跨域問題。說句實話跨域配置錯誤80%都是前四種情況真正涉及到復(fù)雜鑒權(quán)場景的反而少。4. 從網(wǎng)絡(luò)跨域到跨時鐘域一種思維模型的遷移4.1 兩個看似不相干的問題底層邏輯驚人一致搜索引擎的熱搜詞里出現(xiàn)了一組有意思的組合——“跨域”和“跨時鐘域”還有“CDC跨時鐘域”和“PCIe彈性緩存如何搞定時鐘頻偏”。我最初以為這些熱詞是算法亂配但仔細一想網(wǎng)絡(luò)領(lǐng)域的“跨域”和芯片設(shè)計領(lǐng)域的“跨時鐘域”CDCClock Domain Crossing在抽象層面確實是一類問題它們都在處理“兩個獨立域之間如何進行可靠的通信”。網(wǎng)絡(luò)里的跨域是瀏覽器所在的頁面環(huán)境源A要訪問另一個環(huán)境源B的資源兩者之間有不同的規(guī)則和信任邊界。芯片里的跨時鐘域是某個時鐘域的信號要被另一個時鐘域采到兩個時鐘域頻率不同、相位不同、彼此異步信號就像從“域A”跑到了“域B”跨過了域的邊界。這兩個問題有個共同的本質(zhì)跨域通信靠的不是“讓兩個域變得一樣”而是“在邊界上建立可靠的協(xié)商機制”。瀏覽器應(yīng)對跨域的方式是讓服務(wù)器聲明Allowed Origin芯片應(yīng)對跨時鐘域的方式是讓跨域信號通過專門的同步邏輯來“告知”目標(biāo)域“這個信號有效”。4.2 跨時鐘域的經(jīng)典處理方式同步器、異步FIFO與彈性緩存跨時鐘域在數(shù)字電路里是出了名的坑信號從快時鐘域傳到慢時鐘域或者從慢傳到快都可能因為建立時間和保持時間不滿足導(dǎo)致采到亞穩(wěn)態(tài)meta-stability就是輸出既不是確定的0也不是確定的1的狀態(tài)。最基礎(chǔ)的處理方式是兩級同步器把跨域的單比特信號先用兩個時鐘周期的觸發(fā)器鏈條打兩拍降低亞穩(wěn)態(tài)向后方電路傳播的概率。這個操作很像網(wǎng)絡(luò)層面的重試機制——第一次采樣可能是錯誤值但打兩拍之后大概率能采到穩(wěn)定值如果還不對后面對應(yīng)機制會兜底。數(shù)據(jù)總線跨時鐘域多比特信號就不能用同步器了因為每個比特可能在不同時刻被采到總線值會變成亂碼。這時通常用異步FIFO寫入端在自己的時鐘域里寫入讀出端在另一個時鐘域里讀出中間用格雷碼同步讀/寫指針保證多比特跨越的時候同一時刻只有一個比特在跳變。彈性緩存Elastic Buffer則是PCIe這類高速串行鏈路里的關(guān)鍵模塊。PCIe發(fā)送端和接收端各自有時鐘通常有幾百ppm百萬分之一的頻偏。如果兩邊時鐘頻率不完全一致累積下來數(shù)據(jù)速率就會出現(xiàn)差異導(dǎo)致接收端要么讀到重復(fù)數(shù)據(jù)要么丟數(shù)據(jù)。彈性緩存的作用就是在這兩個頻率不完全一致的時鐘域之間充當(dāng)緩沖池并配上接收側(cè)時鐘恢復(fù)電路CDR不斷修正采樣時刻最終把發(fā)送端時鐘域的數(shù)據(jù)安全地搬到接收端時鐘域里。4.3 PCIe彈性緩存對“跨時鐘域”思路的詮釋我讀了一些資料后越看越覺得PCIe彈性緩存的設(shè)計思路和CORS有異曲同工之妙。發(fā)送端不知道自己發(fā)出的信號什么時候會被對端采到它也不關(guān)心它只負責(zé)把數(shù)據(jù)放到鏈路上并隱含在數(shù)據(jù)流里提供時鐘信息接收端則通過CDR和彈性緩沖把數(shù)據(jù)正確地“接收”下來。對應(yīng)到網(wǎng)絡(luò)跨域場景前端不知道后端什么時候會響應(yīng)、會不會帶CORS頭但它會在收到響應(yīng)時校驗響應(yīng)頭里的Access-Control-Allow-Origin后端也不知道前端會不會發(fā)預(yù)檢請求但CORS規(guī)范里約定了遇到OPTIONS要怎么回應(yīng)。兩邊不需要“同源”只需要在邊界上有協(xié)商機制這個協(xié)商機制做對了數(shù)據(jù)就能穩(wěn)定流動。這種類比最大的價值不是技術(shù)實現(xiàn)而是思考方式。當(dāng)你在某個領(lǐng)域里遇到“跨域”問題先別急著搜“怎么繞過去”而是應(yīng)該問一句這個域之間有沒有協(xié)商機制協(xié)商的觸發(fā)條件是什么失敗后的報錯信息是在提示什么想清楚這三個問題無論是網(wǎng)絡(luò)跨域還是跨時鐘域都能找到自己的排查路徑。5. 真實項目中的跨域?qū)崙?zhàn)筆記從開發(fā)到部署5.1 開發(fā)環(huán)境用代理把“跨域”變成“同域”寫代碼的時候我會刻意區(qū)分跨域問題的解決場景。開發(fā)環(huán)境里我最推薦用代理因為代理能讓前端頁面和接口看起來同源省去了后端配置CORS頭的麻煩。vue里我一般這樣配const target process.env.VUE_APP_API_TARGET || http://localhost:8000; module.exports { devServer: { port: 8080, proxy: { /api: { target, changeOrigin: true, pathRewrite: { ^/api: }, // 關(guān)鍵把真實的Host傳給后端 headers: { X-Forwarded-Host: localhost:8080 } } } } };這里有個細節(jié)changeOrigin: true會修改請求頭里的Host字段為target的值后端拿到請求后會以為自己處理的是來自localhost:8000的請求有時候會影響到一些基于Host生成鏈接的邏輯。如果后端需要知道前端的真實地址就通過我上面說的X-Forwarded-Host或者自定義頭傳遞。有些朋友問我“vue配置跨域代理后如何獲取我的真實的請求地址”其實答案就在請求頭里你只需要在后端讀取X-Forwarded-For和X-Forwarded-Host這兩個字段前一個是真實客戶端IP后一個是真實Host。開發(fā)環(huán)境配好后還要確認一件事后端接口不再需要額外配CORS了嗎其實可以配也可以不配。如果不配開發(fā)時用代理沒任何問題但如果測試環(huán)境也要獨立調(diào)前端那最好后端把CORS配好不然每個環(huán)境都得配一套代理維護成本高。5.2 生產(chǎn)環(huán)境nginx反向代理是終極方案生產(chǎn)環(huán)境我?guī)缀醵纪扑]用nginx反向代理來部署現(xiàn)在docker里面也經(jīng)常用Nginx作為入口。無論是純前端項目還是前后端分離的項目用一個域名承載所有服務(wù)是最省心的。前端靜態(tài)文件交給nginx后端接口路徑通過location轉(zhuǎn)發(fā)到內(nèi)部服務(wù)瀏覽器視角下一切同源跨域自然不存在。如果你有多個后端服務(wù)可以這樣擴展server { listen 80; location /api/user/ { proxy_pass http://user-service:8001; } location /api/order/ { proxy_pass http://order-service:8002; } }這種部署方式還能順帶解決Cookie跨域的問題因為統(tǒng)一域名后Cookie的Domain屬性不用特殊處理。5.3 谷歌瀏覽器跨域登錄攜帶Cookie的細節(jié)如果前后端確實分域部署又想實現(xiàn)登錄狀態(tài)跨域攜帶那就需要處理Cookie的SameSite屬性和跨域攜帶問題。首先后端設(shè)置Cookie時要允許跨域攜帶并且把SameSite設(shè)為None同時必須開啟Secure要求HTTPS。Chrome從80版本開始對跨域請求的Cookie策略收緊了很多如果SameSiteNone不帶Secure屬性Cookie會被直接丟棄。Set-Cookie示例Set-Cookie: sessionidabc123; Domainapi.example.com; Path/; SameSiteNone; Secure前端發(fā)請求時要設(shè)置withCredentials: true比如axios里axios.defaults.withCredentials true;然后CORS響應(yīng)頭必須落到具體源前面講的Access-Control-Allow-Origin: https://www.example.com Access-Control-Allow-Credentials: true這個鏈路走通的先決條件很多任何一環(huán)不對都會出現(xiàn)“谷歌瀏覽器跨域登錄失敗”。我的經(jīng)驗是能用統(tǒng)一域名就別分域?qū)嵲谝钟蛑辽僖崆案\維確認證書和HTTPS是否到位因為你一旦用了SameSiteNone; SecureHTTP環(huán)境下Cookie根本帶不上去。5.4 一份實用的踩坑清單把我在不同項目里踩過的坑匯總一下希望對后來者有用場景現(xiàn)象真實原因前端配了代理后端仍報跨域接口能通但控制臺有跨域錯代理沒生效請求直接打到了后端檢查/api前綴和changeOriginCORS配了*后帶Cookie失敗請求被攔截credentials模式下不允許通配符需要改成具體源GET正常POST跨域失敗預(yù)檢請求沒有通過后端沒處理OPTIONS請求或者預(yù)檢響應(yīng)頭缺失vue打包部署后接口404跨域倒是沒了接口地址不對nginx缺少location轉(zhuǎn)發(fā)規(guī)則請求打到靜態(tài)目錄代理后拿不到用戶真實IP后端日志全是localhost缺少X-Forwarded-For和Host傳遞配置跨域登錄失效登錄接口返回成功但Cookie沒種上SameSite屬性沒設(shè)為None或Secure未開啟第七個坑在最后補充一下跨域接口返回200但前端拿不到數(shù)據(jù)很多時候不是跨域的問題而是后端返回的響應(yīng)體里帶了未轉(zhuǎn)義的HTML或者非法JSON瀏覽器解析失敗。所以排查時別只盯著跨域這一個方向先看響應(yīng)體是否合法再考慮CORS的鍋。5.5 配置跨域時容易被忽略的“半路攔截”有一個情況我碰到過兩次值得單獨說一說前端請求已經(jīng)發(fā)出去了后端也返回了CORS頭但是中間有一層網(wǎng)關(guān)或者WAF把響應(yīng)頭里的Access-Control-Allow-Origin值給重寫或者過濾掉了。比如有一次在一個電商項目里前端發(fā)現(xiàn)跨域報錯把后端返回頭打了日志出來明明有Access-Control-Allow-Origin: https://www.example.com但瀏覽器收到的卻是空后來排查到是網(wǎng)關(guān)層的一個安全策略把所有帶“Origin”字樣的響應(yīng)頭都給濾掉了。這類問題排查起來特別痛苦因為按照常規(guī)鏈路查后端是對的前端也是對的但中間環(huán)節(jié)出了問題。所以我建議在排查跨域時除了用瀏覽器開發(fā)者工具最好直接curl請求接口看一眼原始響應(yīng)頭瀏覽器沒加多余的東西你能看到網(wǎng)關(guān)經(jīng)過后的最終結(jié)果。curl命令curl -i https://api.example.com/api/user如果curl返回的響應(yīng)頭里沒有CORS相關(guān)字段而你的代碼里明明設(shè)置了那就說明中間鏈路有東西在動手腳去查網(wǎng)關(guān)和CDN配置。6. 從熱詞看產(chǎn)業(yè)趨勢跨域問題的演進與終局思考6.1 為什么跨域相關(guān)的技術(shù)詞匯持續(xù)熱門搜索引擎里跟跨域綁在一起的熱詞除了最經(jīng)典的“同源策略”、“JSONP”、“CORS”還有“vuedjango打包部署”、“vue配置跨域代理”、“跨域訪問被拒絕”這些非常具體的開發(fā)問題組合。這說明大家不是在研究跨域的理論知識而是真刀真槍寫業(yè)務(wù)時被卡住了。我在社區(qū)里經(jīng)?？吹接腥苏f“跨域不就是加個響應(yīng)頭的事”這種說法在市場前端的崗位上倒還行但如果要負責(zé)運維部署、要跟網(wǎng)關(guān)層打交道、要處理登錄態(tài)跨域只懂加響應(yīng)頭是遠遠不夠的?？缬騿栴}其實是前端工程化、前后端分離架構(gòu)、微服務(wù)化演進共同作用下的產(chǎn)物項目越解耦涉及的服務(wù)域名就越多跨域配置就越需要被當(dāng)作架構(gòu)的一部分來設(shè)計而不是每個服務(wù)各自隨便加幾個頭就完事。6.2 跨域方案的技術(shù)演進從JSONP到統(tǒng)一網(wǎng)關(guān)如果回頭去看技術(shù)演進JSONP是前端在“沒法改后端配置”時代的一種無奈之選它巧妙但局限。CORS是瀏覽器、服務(wù)器、開發(fā)者共同約定的標(biāo)準(zhǔn)化方案是目前的主流。而到了微服務(wù)和云原生時代跨域正在被前移到網(wǎng)關(guān)層統(tǒng)一處理網(wǎng)關(guān)負責(zé)鑒權(quán)、路由和CORS的集中配置后端服務(wù)不再關(guān)心接入方的源是哪個只要信任網(wǎng)關(guān)即可。在這種架構(gòu)下“跨域”這個概念其實正在被“網(wǎng)關(guān)策略”替代——你不需要給每個服務(wù)分別配置一堆響應(yīng)頭只要在入口處設(shè)置好允許的源和方法然后內(nèi)部服務(wù)間通信完全不用考慮同源策略因為那是服務(wù)端到服務(wù)端的資源訪問瀏覽器同源策略管不到。這也是為什么我認為沒必要把跨域當(dāng)成一道硬骨頭去啃更值得做的是在架構(gòu)層面想清楚哪些源是可信的哪些路徑是對外的哪些接口需要攜帶憑據(jù)然后把這些規(guī)則集中管理起來。6.3 跨域思維在更廣泛技術(shù)領(lǐng)域的延伸除了芯片設(shè)計里的跨時鐘域類似“跨域”的思維模型還能在不少地方看到。區(qū)塊鏈里的跨鏈通信要解決不同鏈之間的信任與數(shù)據(jù)一致性微服務(wù)之間的服務(wù)調(diào)用要處理好不同命名空間的資源隔離大型系統(tǒng)的時間同步里有跨時區(qū)、跨NTP服務(wù)器的偏差問題。它們在實現(xiàn)細節(jié)上天差地別但本質(zhì)上都是要回答同一個問題如何在一個不可信的邊界上建立可靠的通信。把視野拉高之后你會發(fā)現(xiàn)“跨域”不是一個需要“消滅”的敵人反而是一種必要的安全邊界設(shè)計。如果沒有同源策略瀏覽器里的任意腳本都能為所欲為如果沒有跨時鐘域的處理機制芯片里的亞穩(wěn)態(tài)會引發(fā)各種未知行為如果沒有跨鏈協(xié)議區(qū)塊鏈網(wǎng)絡(luò)無法安全互通成為更大的價值網(wǎng)絡(luò)。我們在業(yè)務(wù)里被跨域問題折騰得死去活來恰恰說明這些安全機制在勤勤懇懇地工作著。這篇文章寫了這么多其實也就是想幫大家把跨域這么個概念從“報錯時怎么解決”拉到“為什么會有這個問題”再往上拉到“這個思維模型還能用在哪”。我自己在最開始接觸CORS配置錯誤時也是一頭霧水后來寫多了踩坑多了才慢慢建立起了自己的排查框架。如果你現(xiàn)在正好被跨域問題卡住不妨先放下復(fù)制粘貼解決方案的念頭打開瀏覽器的Network面板把一個請求的完整鏈路從頭到尾過一遍看請求頭、看響應(yīng)頭、看預(yù)檢、看網(wǎng)關(guān)往往問題的答案就在這些細節(jié)里。 跨域問題深度解析：同源策略、CORS與代理實戰(zhàn)
遇到過“跨域訪問被拒絕請檢查瀏覽器配置!”這種提示的人大概率會經(jīng)歷三個階段先是懷疑瀏覽器壞了然后懷疑后端代碼有問題最后查了一圈發(fā)現(xiàn)是既不完全是瀏覽器也不是后端的“機制”在起作用?？缬騿栴}就是這么擰巴它明明不是代碼邏輯錯誤卻能讓前后端聯(lián)調(diào)陷入僵局而且?guī)缀趺總€做Web開發(fā)的人都會遇到。更魔幻的是你搜到的解決方案往往只有一句“加個請求頭”或者“開個代理”卻沒人告訴你為什么瀏覽器要攔你、后端怎么配才是對的、代理轉(zhuǎn)發(fā)之后請求到底從哪來。我在經(jīng)歷過php后端配JSONP、vue開發(fā)代理、django打包部署后nginx調(diào)CORS、還有谷歌瀏覽器跨域登錄帶Cookie這些場景之后才把跨域這攤事情徹底理順。這篇文章就照著我的真實踩坑路徑來寫從同源策略的底層邏輯講起把JSONP、CORS、代理轉(zhuǎn)發(fā)這些方案掰開揉碎最后再分享一個讓我很受啟發(fā)的視角——網(wǎng)絡(luò)里的“跨域”和芯片設(shè)計里的“跨時鐘域”CDC本質(zhì)上是同一類問題想通了這一點很多配置就不再是死記硬背了。1. 同源策略到底在保護什么從一次真實報錯講起1.1 那個“請檢查瀏覽器配置”的誤導(dǎo)性提示先還原一下我遇到過的一個經(jīng)典場面。前端頁面跑在http://localhost:8080后端接口在http://localhost:8000頁面里用fetch發(fā)起請求控制臺報錯信息被某些框架包裝成了“跨域訪問被拒絕請檢查瀏覽器配置!”。我當(dāng)時第一反應(yīng)是Chrome的安全設(shè)置出問題了畢竟提示文字直指瀏覽器配置結(jié)果翻遍設(shè)置也沒找出個開關(guān)來。后來才知道這個提示的準(zhǔn)確意思是“瀏覽器攔截了來自http://localhost:8080對http://localhost:8000的請求”而攔截的依據(jù)就是同源策略。報錯信息之所以寫得像“瀏覽器配置”問題是因為很多封裝庫為了照顧業(yè)務(wù)開發(fā)者的情緒把錯誤信息人性化處理了但恰恰是這個處理讓排查方向跑偏。真實情況是瀏覽器沒有配置錯后端接口也沒有宕機只是這兩個地址的“源”不同。1.2 同源的三要素協(xié)議、域名、端口“源”這個概念簡單說就是協(xié)議加域名加端口三位一體任何一個不一樣就算跨域。頁面地址請求地址是否同源原因http://example.com/pagehttp://example.com/api同源協(xié)議域名端口全一致http://example.comhttps://example.com跨域協(xié)議不同http://example.comhttp://api.example.com跨域域名不同http://example.com:8080http://example.com跨域端口不同很多人在自己機器上聯(lián)調(diào)沒事一上測試環(huán)境就開始跨域多半就是端口或者域名變了。比如后端從localhost:8000換成了內(nèi)網(wǎng)IP加端口前端代碼里的請求地址沒跟著改或者反向代理的路徑?jīng)]對上。我之前幫人排查過一個vue項目開發(fā)時代理配得好好的打包部署到nginx后就瘋狂報跨域最后發(fā)現(xiàn)是nginx監(jiān)聽的是127.0.0.1:80而前端頁面用IP訪問也屬于源不一致。1.3 瀏覽器為什么要“多管閑事”如果瀏覽器不做同源策略會發(fā)生什么想象你登錄了銀行系統(tǒng)保持會話狀態(tài)然后打開另一個惡意網(wǎng)站。惡意網(wǎng)站的腳本如果可以直接請求銀行接口就能以你的身份轉(zhuǎn)賬、改密碼。同源策略就是一道隔離墻讓A網(wǎng)站里的腳本只能訪問A網(wǎng)站的數(shù)據(jù)碰不到B網(wǎng)站。這里有個關(guān)鍵點同源策略是瀏覽器的行為不是HTTP協(xié)議本身的約束。服務(wù)器之間發(fā)起請求完全不受同源策略限制。這意味著php后端訪問python后端、curl命令直連接口都不會有跨域問題?？缬蜻@道坎只存在于瀏覽器環(huán)境里是瀏覽器主動幫你擋住了“跨源”的頁面發(fā)起“跨源”的請求。所以CORS的解決方案也很有意思——不是讓瀏覽器放開限制而是讓目標(biāo)服務(wù)器明確告訴瀏覽器“這個源我可以信任”瀏覽器收到這個聲明后才放行。另外還要補充一點同源策略并沒有一竿子打死所有跨源資源script、img、link這些標(biāo)簽天然允許跨域加載這也是JSONP方案能存在的前提。明白了這一點你就能理解為什么JSONP只能用GET請求——它本質(zhì)上是動態(tài)創(chuàng)建一個script標(biāo)簽來加載數(shù)據(jù)script標(biāo)簽不是XMLHttpRequest自然只能發(fā)GET。2. 繞過跨域的幾種姿勢與它們的使用邊界2.1 JSONP老牌方案的原理與php側(cè)配合JSONP的思路很直白既然script標(biāo)簽跨域加載不受限制那就把接口數(shù)據(jù)包裝成一段JavaScript代碼用script標(biāo)簽加載回來。前端定義好回調(diào)函數(shù)后端返回callback({...})的形式script加載完就自動執(zhí)行。我在php項目里配合過一個JSONP接口后端代碼大致是這樣?php $callback $_GET[callback] ?? ; $data [code 0, data [name test]]; if ($callback) { header(Content-Type: application/javascript); echo $callback . ( . json_encode($data) . ); } else { header(Content-Type: application/json); echo json_encode($data); }前端調(diào)用function handleData(res) { console.log(res); } const script document.createElement(script); script.src http://api.example.com/user?callbackhandleData; document.body.appendChild(script);這種方式在配合不好的情況下會讓人抓狂因為它有幾個硬傷只能GET、沒有錯誤處理機制接口掛了頁面直接報錯你很難拿到錯誤碼、而且容易造成回調(diào)函數(shù)全局污染。所以現(xiàn)在JSONP基本只在維護老項目或者對接第三方老接口時才會用到。如果你在2020年之后的新項目里看到有人還在主張用JSONP那基本可以判斷對方是沒怎么接觸過CORS的老選手。2.2 CORS當(dāng)前的主流方案后端跨域配置的完整鏈路CORS的全稱是跨域資源共享它和JSONP最大的區(qū)別在于它不是繞過同源策略而是讓服務(wù)器顯式聲明允許哪些源訪問。瀏覽器發(fā)現(xiàn)請求是跨域的會先看服務(wù)器的響應(yīng)頭里有沒有Access-Control-Allow-Origin如果有并且包含了當(dāng)前源就放行否則就攔截并報錯。后端要做的是在響應(yīng)里添加跨域響應(yīng)頭。我以php和django為例寫下最基礎(chǔ)的配置。php接口加頭header(Access-Control-Allow-Origin: http://localhost:8080); header(Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS); header(Access-Control-Allow-Headers: Content-Type, Authorization);django里可以寫個中間件class CorsMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): response self.get_response(request) response[Access-Control-Allow-Origin] http://localhost:8080 response[Access-Control-Allow-Methods] GET, POST, PUT, DELETE, OPTIONS response[Access-Control-Allow-Headers] Content-Type, Authorization return response配置CORS時有個很容易踩的坑后面第3節(jié)我會單獨展開講通配符和credentials的沖突問題。這里先記住一個核心原則Access-Control-Allow-Origin不要隨便寫*尤其是涉及登錄狀態(tài)時要更謹慎。2.3 代理轉(zhuǎn)發(fā)開發(fā)環(huán)境的最優(yōu)解以及一個困擾很多人的問題如果你用的是vue-cli或者vite開發(fā)環(huán)境配跨域代理是效率最高的方式。原理很簡單瀏覽器只跟同源的開發(fā)服務(wù)器通信開發(fā)服務(wù)器收到請求后再轉(zhuǎn)發(fā)給真實后端轉(zhuǎn)發(fā)過程發(fā)生在服務(wù)端不受瀏覽器同源策略限制。vue.config.js里的典型配置module.exports { devServer: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true, pathRewrite: { ^/api: } } } } };不過配置完代理之后很多人會遇到一個困惑我在后端接口里想要拿到用戶的真實請求地址結(jié)果發(fā)現(xiàn)所有請求的地址都變成了http://localhost:8080后端拿不到客戶端真實IP。這個問題的根源在于代理服務(wù)器默認會替換掉Host頭后端的請求日志里看到的統(tǒng)一是代理服務(wù)器的地址。解決辦法是在代理配置里通過headers設(shè)置Host或者在nginx層用proxy_set_header Host $host;把真實的Host信息傳給后端。簡單說代理只是幫你把請求轉(zhuǎn)發(fā)出去但如果你需要完整的真實請求鏈路信息必須在代理層顯式傳遞X-Forwarded-For、Host這些頭。2.4 其他方案postMessage與document.domain等postMessage適合iframe跨域通信的場景比如頁面里嵌入了其他域名的iframe雙方通過postMessage和message事件來交換數(shù)據(jù)。這個方法比較冷門但處理跨域iframe的交互時幾乎是唯一選擇。document.domain只能在同一個主域名下的子域之間使用比如a.example.com和b.example.com可以把domain改為example.com實現(xiàn)通信但這會把子域的隔離性破壞掉現(xiàn)在用的人很少。WebSocket天然支持跨域握手階段由服務(wù)器校驗Origin業(yè)務(wù)里如果長連接需求多可以直接走這個不用糾結(jié)CORS。這些方案我給出的排序是新項目一律上CORS開發(fā)環(huán)境用代理提速遇到iframe通信再去看postMessageJSONP只用于老接口兼容。3. CORS配置錯誤排查從“failed to load”到“預(yù)檢請求”的完整鏈路3.1 Access-Control-Allow-Origin的瘋狂踩坑通配符與credentials有一次我在做一個帶登錄態(tài)的跨域請求前端設(shè)置了withCredentials: true后端也很老實地配了Access-Control-Allow-Origin: *但請求還是報錯。錯誤提示是“The value of the Access-Control-Allow-Origin header in the response must not be the wildcard * when the requests credentials mode is include”。這個坑特別隱蔽因為單看響應(yīng)頭Access-Control-Allow-Origin: *是合法的但一旦請求帶了Cookie瀏覽器就不允許通配符了。原理在于如果允許*加憑據(jù)任何網(wǎng)站都可以拿著你的Cookie去請求這個接口不需要服務(wù)器顯式信任任何源這等于把同源策略的隔離墻拆了。正確的做法是指定具體的源比如Access-Control-Allow-Origin: http://localhost:8080 Access-Control-Allow-Credentials: true而且要特別注意的是這兩個頭必須配合使用只加Access-Control-Allow-Credentials不加具體的Origin也不行。我在一個項目里看到后端處理跨域的邏輯是直接反射請求頭里的Origin再返回這樣乍一看能通配所有域名但安全隱患極大——因為你相當(dāng)于對所有源都放行了同源策略形同虛設(shè)。正確做法是維護一個白名單代碼里判斷請求頭里Origin是否在白名單中命中才返回對應(yīng)的頭。3.2 預(yù)檢請求OPTIONS瀏覽器的小心試探很多人第一次看到OPTIONS請求時會蒙圈我明明發(fā)的POST為什么瀏覽器先發(fā)了個OPTIONS這就是CORS的預(yù)檢機制。當(dāng)你的請求滿足一定條件時比如用了Content-Type: application/json、自定義請求頭、或者非GET/HEAD/POST方法瀏覽器會先發(fā)一個OPTIONS請求問服務(wù)器我這個跨域請求你允許嗎允許的話我再發(fā)真正的請求。服務(wù)器處理邏輯里如果沒覆蓋OPTIONS方法預(yù)檢請求就會得到非2xx的響應(yīng)瀏覽器直接阻止真實請求發(fā)出。我在django里給接口加裝飾器時遇到過一種情況GET接口正常POST接口死活跨域失敗后來發(fā)現(xiàn)是POST請求帶JSON體觸發(fā)了預(yù)檢而后端路由沒處理OPTIONS。解決方式一般有兩種要么在后端對OPTIONS統(tǒng)一放行要么用第三方庫的CORS中間件來接管。flask里直接用flask-corsdjango用django-cors-headers比自己手寫響應(yīng)頭省心很多因為這類庫已經(jīng)把預(yù)檢、鑒權(quán)、白名單這些邊界情況都處理好了。用庫并不是偷懶這些邊界情況自己重寫一遍成本極高。3.3 vuedjango打包部署后無法跨域nginx層的關(guān)鍵配置開發(fā)環(huán)境下vue的代理配置得好好的一打包部署就各種問題首先是前端請求的地址變了。開發(fā)時你請求的是/api代理會幫你轉(zhuǎn)發(fā)但打包后如果只把靜態(tài)文件丟到nginx沒有對應(yīng)的/api轉(zhuǎn)發(fā)規(guī)則請求就會打到nginx自己身上然后404或者觸發(fā)跨域。我常用的nginx配置是這樣的server { listen 80; server_name example.com; # 前端靜態(tài)文件 location / { root /var/www/frontend; index index.html; try_files $uri $uri/ /index.html; } # 后端接口反向代理 location /api/ { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }這種情況下根本不需要CORS因為瀏覽器訪問的源是example.com它請求的/api也指向example.com兩者同源。這才是生產(chǎn)環(huán)境最推薦的部署方式前端和后端共用一個域名通過路徑區(qū)分徹底繞開跨域。如果你非要前后端分開部署比如前端在cdn.example.com后端在api.example.com那就在nginx層給后端加上CORS頭location / { add_header Access-Control-Allow-Origin https://cdn.example.com always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS, PUT, DELETE always; add_header Access-Control-Allow-Headers Content-Type, Authorization always; add_header Access-Control-Allow-Credentials true always; if ($request_method OPTIONS) { return 204; } }注意add_header后面的always參數(shù)如果沒有它某些場景下比如響應(yīng)碼非200頭可能不會加進去排查時會很困惑。3.4 一個完整的跨域問題排查鏈路我把自己常用的排查順序整理成了一張清單遇到跨域問題按這個順序查基本十幾分鐘內(nèi)能定位打開瀏覽器控制臺Network看請求到底發(fā)出去了沒有。如果請求是紅色的failed點開Response Headers看有沒有Access-Control-Allow-Origin。如果沒有這個頭說明是后端沒配置CORS問題在服務(wù)端去查后端中間件或nginx配置。如果有這個頭但值不是當(dāng)前頁面的源說明白名單沒匹配上去查Origin配置。如果請求帶上Cookie還報錯查Access-Control-Allow-Credentials是否為true且Access-Control-Allow-Origin是否為具體源而非*。如果看到兩次請求一次OPTIONS一次POST查OPTIONS請求的響應(yīng)碼非2xx就說明預(yù)檢沒過。這個方法幫我解決過不下幾十個跨域問題。說句實話跨域配置錯誤80%都是前四種情況真正涉及到復(fù)雜鑒權(quán)場景的反而少。4. 從網(wǎng)絡(luò)跨域到跨時鐘域一種思維模型的遷移4.1 兩個看似不相干的問題底層邏輯驚人一致搜索引擎的熱搜詞里出現(xiàn)了一組有意思的組合——“跨域”和“跨時鐘域”還有“CDC跨時鐘域”和“PCIe彈性緩存如何搞定時鐘頻偏”。我最初以為這些熱詞是算法亂配但仔細一想網(wǎng)絡(luò)領(lǐng)域的“跨域”和芯片設(shè)計領(lǐng)域的“跨時鐘域”CDCClock Domain Crossing在抽象層面確實是一類問題它們都在處理“兩個獨立域之間如何進行可靠的通信”。網(wǎng)絡(luò)里的跨域是瀏覽器所在的頁面環(huán)境源A要訪問另一個環(huán)境源B的資源兩者之間有不同的規(guī)則和信任邊界。芯片里的跨時鐘域是某個時鐘域的信號要被另一個時鐘域采到兩個時鐘域頻率不同、相位不同、彼此異步信號就像從“域A”跑到了“域B”跨過了域的邊界。這兩個問題有個共同的本質(zhì)跨域通信靠的不是“讓兩個域變得一樣”而是“在邊界上建立可靠的協(xié)商機制”。瀏覽器應(yīng)對跨域的方式是讓服務(wù)器聲明Allowed Origin芯片應(yīng)對跨時鐘域的方式是讓跨域信號通過專門的同步邏輯來“告知”目標(biāo)域“這個信號有效”。4.2 跨時鐘域的經(jīng)典處理方式同步器、異步FIFO與彈性緩存跨時鐘域在數(shù)字電路里是出了名的坑信號從快時鐘域傳到慢時鐘域或者從慢傳到快都可能因為建立時間和保持時間不滿足導(dǎo)致采到亞穩(wěn)態(tài)meta-stability就是輸出既不是確定的0也不是確定的1的狀態(tài)。最基礎(chǔ)的處理方式是兩級同步器把跨域的單比特信號先用兩個時鐘周期的觸發(fā)器鏈條打兩拍降低亞穩(wěn)態(tài)向后方電路傳播的概率。這個操作很像網(wǎng)絡(luò)層面的重試機制——第一次采樣可能是錯誤值但打兩拍之后大概率能采到穩(wěn)定值如果還不對后面對應(yīng)機制會兜底。數(shù)據(jù)總線跨時鐘域多比特信號就不能用同步器了因為每個比特可能在不同時刻被采到總線值會變成亂碼。這時通常用異步FIFO寫入端在自己的時鐘域里寫入讀出端在另一個時鐘域里讀出中間用格雷碼同步讀/寫指針保證多比特跨越的時候同一時刻只有一個比特在跳變。彈性緩存Elastic Buffer則是PCIe這類高速串行鏈路里的關(guān)鍵模塊。PCIe發(fā)送端和接收端各自有時鐘通常有幾百ppm百萬分之一的頻偏。如果兩邊時鐘頻率不完全一致累積下來數(shù)據(jù)速率就會出現(xiàn)差異導(dǎo)致接收端要么讀到重復(fù)數(shù)據(jù)要么丟數(shù)據(jù)。彈性緩存的作用就是在這兩個頻率不完全一致的時鐘域之間充當(dāng)緩沖池并配上接收側(cè)時鐘恢復(fù)電路CDR不斷修正采樣時刻最終把發(fā)送端時鐘域的數(shù)據(jù)安全地搬到接收端時鐘域里。4.3 PCIe彈性緩存對“跨時鐘域”思路的詮釋我讀了一些資料后越看越覺得PCIe彈性緩存的設(shè)計思路和CORS有異曲同工之妙。發(fā)送端不知道自己發(fā)出的信號什么時候會被對端采到它也不關(guān)心它只負責(zé)把數(shù)據(jù)放到鏈路上并隱含在數(shù)據(jù)流里提供時鐘信息接收端則通過CDR和彈性緩沖把數(shù)據(jù)正確地“接收”下來。對應(yīng)到網(wǎng)絡(luò)跨域場景前端不知道后端什么時候會響應(yīng)、會不會帶CORS頭但它會在收到響應(yīng)時校驗響應(yīng)頭里的Access-Control-Allow-Origin后端也不知道前端會不會發(fā)預(yù)檢請求但CORS規(guī)范里約定了遇到OPTIONS要怎么回應(yīng)。兩邊不需要“同源”只需要在邊界上有協(xié)商機制這個協(xié)商機制做對了數(shù)據(jù)就能穩(wěn)定流動。這種類比最大的價值不是技術(shù)實現(xiàn)而是思考方式。當(dāng)你在某個領(lǐng)域里遇到“跨域”問題先別急著搜“怎么繞過去”而是應(yīng)該問一句這個域之間有沒有協(xié)商機制協(xié)商的觸發(fā)條件是什么失敗后的報錯信息是在提示什么想清楚這三個問題無論是網(wǎng)絡(luò)跨域還是跨時鐘域都能找到自己的排查路徑。5. 真實項目中的跨域?qū)崙?zhàn)筆記從開發(fā)到部署5.1 開發(fā)環(huán)境用代理把“跨域”變成“同域”寫代碼的時候我會刻意區(qū)分跨域問題的解決場景。開發(fā)環(huán)境里我最推薦用代理因為代理能讓前端頁面和接口看起來同源省去了后端配置CORS頭的麻煩。vue里我一般這樣配const target process.env.VUE_APP_API_TARGET || http://localhost:8000; module.exports { devServer: { port: 8080, proxy: { /api: { target, changeOrigin: true, pathRewrite: { ^/api: }, // 關(guān)鍵把真實的Host傳給后端 headers: { X-Forwarded-Host: localhost:8080 } } } } };這里有個細節(jié)changeOrigin: true會修改請求頭里的Host字段為target的值后端拿到請求后會以為自己處理的是來自localhost:8000的請求有時候會影響到一些基于Host生成鏈接的邏輯。如果后端需要知道前端的真實地址就通過我上面說的X-Forwarded-Host或者自定義頭傳遞。有些朋友問我“vue配置跨域代理后如何獲取我的真實的請求地址”其實答案就在請求頭里你只需要在后端讀取X-Forwarded-For和X-Forwarded-Host這兩個字段前一個是真實客戶端IP后一個是真實Host。開發(fā)環(huán)境配好后還要確認一件事后端接口不再需要額外配CORS了嗎其實可以配也可以不配。如果不配開發(fā)時用代理沒任何問題但如果測試環(huán)境也要獨立調(diào)前端那最好后端把CORS配好不然每個環(huán)境都得配一套代理維護成本高。5.2 生產(chǎn)環(huán)境nginx反向代理是終極方案生產(chǎn)環(huán)境我?guī)缀醵纪扑]用nginx反向代理來部署現(xiàn)在docker里面也經(jīng)常用Nginx作為入口。無論是純前端項目還是前后端分離的項目用一個域名承載所有服務(wù)是最省心的。前端靜態(tài)文件交給nginx后端接口路徑通過location轉(zhuǎn)發(fā)到內(nèi)部服務(wù)瀏覽器視角下一切同源跨域自然不存在。如果你有多個后端服務(wù)可以這樣擴展server { listen 80; location /api/user/ { proxy_pass http://user-service:8001; } location /api/order/ { proxy_pass http://order-service:8002; } }這種部署方式還能順帶解決Cookie跨域的問題因為統(tǒng)一域名后Cookie的Domain屬性不用特殊處理。5.3 谷歌瀏覽器跨域登錄攜帶Cookie的細節(jié)如果前后端確實分域部署又想實現(xiàn)登錄狀態(tài)跨域攜帶那就需要處理Cookie的SameSite屬性和跨域攜帶問題。首先后端設(shè)置Cookie時要允許跨域攜帶并且把SameSite設(shè)為None同時必須開啟Secure要求HTTPS。Chrome從80版本開始對跨域請求的Cookie策略收緊了很多如果SameSiteNone不帶Secure屬性Cookie會被直接丟棄。Set-Cookie示例Set-Cookie: sessionidabc123; Domainapi.example.com; Path/; SameSiteNone; Secure前端發(fā)請求時要設(shè)置withCredentials: true比如axios里axios.defaults.withCredentials true;然后CORS響應(yīng)頭必須落到具體源前面講的Access-Control-Allow-Origin: https://www.example.com Access-Control-Allow-Credentials: true這個鏈路走通的先決條件很多任何一環(huán)不對都會出現(xiàn)“谷歌瀏覽器跨域登錄失敗”。我的經(jīng)驗是能用統(tǒng)一域名就別分域?qū)嵲谝钟蛑辽僖崆案\維確認證書和HTTPS是否到位因為你一旦用了SameSiteNone; SecureHTTP環(huán)境下Cookie根本帶不上去。5.4 一份實用的踩坑清單把我在不同項目里踩過的坑匯總一下希望對后來者有用場景現(xiàn)象真實原因前端配了代理后端仍報跨域接口能通但控制臺有跨域錯代理沒生效請求直接打到了后端檢查/api前綴和changeOriginCORS配了*后帶Cookie失敗請求被攔截credentials模式下不允許通配符需要改成具體源GET正常POST跨域失敗預(yù)檢請求沒有通過后端沒處理OPTIONS請求或者預(yù)檢響應(yīng)頭缺失vue打包部署后接口404跨域倒是沒了接口地址不對nginx缺少location轉(zhuǎn)發(fā)規(guī)則請求打到靜態(tài)目錄代理后拿不到用戶真實IP后端日志全是localhost缺少X-Forwarded-For和Host傳遞配置跨域登錄失效登錄接口返回成功但Cookie沒種上SameSite屬性沒設(shè)為None或Secure未開啟第七個坑在最后補充一下跨域接口返回200但前端拿不到數(shù)據(jù)很多時候不是跨域的問題而是后端返回的響應(yīng)體里帶了未轉(zhuǎn)義的HTML或者非法JSON瀏覽器解析失敗。所以排查時別只盯著跨域這一個方向先看響應(yīng)體是否合法再考慮CORS的鍋。5.5 配置跨域時容易被忽略的“半路攔截”有一個情況我碰到過兩次值得單獨說一說前端請求已經(jīng)發(fā)出去了后端也返回了CORS頭但是中間有一層網(wǎng)關(guān)或者WAF把響應(yīng)頭里的Access-Control-Allow-Origin值給重寫或者過濾掉了。比如有一次在一個電商項目里前端發(fā)現(xiàn)跨域報錯把后端返回頭打了日志出來明明有Access-Control-Allow-Origin: https://www.example.com但瀏覽器收到的卻是空后來排查到是網(wǎng)關(guān)層的一個安全策略把所有帶“Origin”字樣的響應(yīng)頭都給濾掉了。這類問題排查起來特別痛苦因為按照常規(guī)鏈路查后端是對的前端也是對的但中間環(huán)節(jié)出了問題。所以我建議在排查跨域時除了用瀏覽器開發(fā)者工具最好直接curl請求接口看一眼原始響應(yīng)頭瀏覽器沒加多余的東西你能看到網(wǎng)關(guān)經(jīng)過后的最終結(jié)果。curl命令curl -i https://api.example.com/api/user如果curl返回的響應(yīng)頭里沒有CORS相關(guān)字段而你的代碼里明明設(shè)置了那就說明中間鏈路有東西在動手腳去查網(wǎng)關(guān)和CDN配置。6. 從熱詞看產(chǎn)業(yè)趨勢跨域問題的演進與終局思考6.1 為什么跨域相關(guān)的技術(shù)詞匯持續(xù)熱門搜索引擎里跟跨域綁在一起的熱詞除了最經(jīng)典的“同源策略”、“JSONP”、“CORS”還有“vuedjango打包部署”、“vue配置跨域代理”、“跨域訪問被拒絕”這些非常具體的開發(fā)問題組合。這說明大家不是在研究跨域的理論知識而是真刀真槍寫業(yè)務(wù)時被卡住了。我在社區(qū)里經(jīng)?？吹接腥苏f“跨域不就是加個響應(yīng)頭的事”這種說法在市場前端的崗位上倒還行但如果要負責(zé)運維部署、要跟網(wǎng)關(guān)層打交道、要處理登錄態(tài)跨域只懂加響應(yīng)頭是遠遠不夠的?？缬騿栴}其實是前端工程化、前后端分離架構(gòu)、微服務(wù)化演進共同作用下的產(chǎn)物項目越解耦涉及的服務(wù)域名就越多跨域配置就越需要被當(dāng)作架構(gòu)的一部分來設(shè)計而不是每個服務(wù)各自隨便加幾個頭就完事。6.2 跨域方案的技術(shù)演進從JSONP到統(tǒng)一網(wǎng)關(guān)如果回頭去看技術(shù)演進JSONP是前端在“沒法改后端配置”時代的一種無奈之選它巧妙但局限。CORS是瀏覽器、服務(wù)器、開發(fā)者共同約定的標(biāo)準(zhǔn)化方案是目前的主流。而到了微服務(wù)和云原生時代跨域正在被前移到網(wǎng)關(guān)層統(tǒng)一處理網(wǎng)關(guān)負責(zé)鑒權(quán)、路由和CORS的集中配置后端服務(wù)不再關(guān)心接入方的源是哪個只要信任網(wǎng)關(guān)即可。在這種架構(gòu)下“跨域”這個概念其實正在被“網(wǎng)關(guān)策略”替代——你不需要給每個服務(wù)分別配置一堆響應(yīng)頭只要在入口處設(shè)置好允許的源和方法然后內(nèi)部服務(wù)間通信完全不用考慮同源策略因為那是服務(wù)端到服務(wù)端的資源訪問瀏覽器同源策略管不到。這也是為什么我認為沒必要把跨域當(dāng)成一道硬骨頭去啃更值得做的是在架構(gòu)層面想清楚哪些源是可信的哪些路徑是對外的哪些接口需要攜帶憑據(jù)然后把這些規(guī)則集中管理起來。6.3 跨域思維在更廣泛技術(shù)領(lǐng)域的延伸除了芯片設(shè)計里的跨時鐘域類似“跨域”的思維模型還能在不少地方看到。區(qū)塊鏈里的跨鏈通信要解決不同鏈之間的信任與數(shù)據(jù)一致性微服務(wù)之間的服務(wù)調(diào)用要處理好不同命名空間的資源隔離大型系統(tǒng)的時間同步里有跨時區(qū)、跨NTP服務(wù)器的偏差問題。它們在實現(xiàn)細節(jié)上天差地別但本質(zhì)上都是要回答同一個問題如何在一個不可信的邊界上建立可靠的通信。把視野拉高之后你會發(fā)現(xiàn)“跨域”不是一個需要“消滅”的敵人反而是一種必要的安全邊界設(shè)計。如果沒有同源策略瀏覽器里的任意腳本都能為所欲為如果沒有跨時鐘域的處理機制芯片里的亞穩(wěn)態(tài)會引發(fā)各種未知行為如果沒有跨鏈協(xié)議區(qū)塊鏈網(wǎng)絡(luò)無法安全互通成為更大的價值網(wǎng)絡(luò)。我們在業(yè)務(wù)里被跨域問題折騰得死去活來恰恰說明這些安全機制在勤勤懇懇地工作著。這篇文章寫了這么多其實也就是想幫大家把跨域這么個概念從“報錯時怎么解決”拉到“為什么會有這個問題”再往上拉到“這個思維模型還能用在哪”。我自己在最開始接觸CORS配置錯誤時也是一頭霧水后來寫多了踩坑多了才慢慢建立起了自己的排查框架。如果你現(xiàn)在正好被跨域問題卡住不妨先放下復(fù)制粘貼解決方案的念頭打開瀏覽器的Network面板把一個請求的完整鏈路從頭到尾過一遍看請求頭、看響應(yīng)頭、看預(yù)檢、看網(wǎng)關(guān)往往問題的答案就在這些細節(jié)里。