本文由雲+社區發表 做過 web 開發的同學，應該都遇到過跨域的問題，當我們從一個功能變數名稱向另一個功能變數名稱發送 Ajax 請求的時候，打開瀏覽器控制台就會看到跨域錯誤，今天我們就來聊聊跨域的問題。 1. 瀏覽器的同源策略 同源的定義是：如果兩個頁面的 \ 協議 ， \ 埠 （如果有指定）和 \ 功能變數名稱 都相 ...
本文由雲+社區發表
做過 web 開發的同學，應該都遇到過跨域的問題，當我們從一個功能變數名稱向另一個功能變數名稱發送 Ajax 請求的時候，打開瀏覽器控制台就會看到跨域錯誤，今天我們就來聊聊跨域的問題。
1. 瀏覽器的同源策略
同源的定義是：如果兩個頁面的*協議，*埠（如果有指定）和*功能變數名稱*都相同，則兩個頁面具有相同的源。同源策略限制了從同一個源載入的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。
2. 跨域錯誤信息產生的原因
為了說明問題，我們可以做如下實驗，我們在本地搭建了開發環境， 由客戶端 http://localhost:3001 向伺服器 http://localhost:3000 發送兩個請求，一個使用 javascript 非同步請求數據，另一個使用 img 標簽請求數據，伺服器收到請求後，列印接收到請求的日誌，如下圖所示：
客戶端發送兩個請求
服務端列印日誌並處理請求
代開客戶端瀏覽器的控制台，可以看到發出了兩個請求，並且都收到了狀態碼為 200 的響應，同時控制台報了一個錯誤，即 xhr 請求報錯。由此我們可以知道，之所以產生跨域錯誤信息，原因有以下三條：
- 瀏覽器端的限制（服務端收到了請求並正確返回）
- 發送的是 XMLHttpRequest 請求（使用 img 標簽發送的請求為 json 類型，並不會報錯）
- 請求了不同域的資源
只有同時滿足了這三個條件，瀏覽器才會產生跨域錯誤。
3. 解決跨域的思路
既然我們知道了跨域錯誤產生的原因，那麼解決思路就很直觀了，針對出錯的三個原因進行相應的處理即可，相應的解決思路也有三個方向：
- 打破瀏覽器的限制
- 不發送 XHR 請求
- 解決跨域
下文將分別進行闡述。
3.1 打破瀏覽器的限制
由上面分析結論可知，之所以出現跨域的錯誤，實際上是客戶端瀏覽器所做的限制，伺服器並未進行限制，因此我們可以通過設置瀏覽器，使其不進行跨域檢查。實際上瀏覽器也提供了對應的設置選項。
以 MacOS 下的 Chrome 瀏覽器為例，在終端中使用命令
open -n /Applications/Google\ Chrome.app/ --args --disable-web-security --user-data-dir=/Users/your-computer-account/MyChromeDevUserData/打開瀏覽器，即可禁用 Chrome 瀏覽器的安全檢查功能，同時也會禁用跨域安全檢查功能，這樣再次拿前面的例子進行測試，發現此時不會報錯，同時也可以正確拿到服務端返回的數據。
禁用瀏覽器安全檢查功能
這種方式雖然可以實現跨域，但是需要每個用戶都對瀏覽器進行設置，同時可能導致潛在的安全隱患，正常情況下不實用。但這個例子充分說明瞭，跨域錯誤是前端瀏覽器所做的限制，與後臺服務無關。
3.2 JSONP實現跨域
根據思路2，既然跨域問題產生的原因是因為客戶端發送了 Ajax 請求，那麼我們打破這個條件即可。具體實現方式就是使用 JSONP 來進行跨域請求。
JSONP，是 JSON with Padding 的簡稱，它是 json 的一種補充使用方式，利用 script 標簽來解決跨域問題。JSONP 是非官方協議，他只是前後端一個約定，如果請求參數帶有約定的參數，則後臺返回 javascript 代碼而非 json 數據，返回代碼是函數調用形式，函數名即約定值，函數參數即要返回的數據。JSONP 的實現原理如下圖所示：
JSONP實現原理
首先在客戶端 js 中定義一個函數（假設名為 handler），然後動態創建一個 script 標簽插入頁面中，script 標簽的 src 屬性即要調用的地址，同時，在調用的 url 中加入一個服務端約定的參數（假設名為 callback，參數值為已定義的函數名 handler），服務端收到請求，如果發現請求的 url 中帶有約定的參數，那麼就返回一段函數調用形式的 javascript 代碼，該段代碼的函數名即為 callback 參數的值 handler，函數的參數即為待返回的數據。這樣，客戶端拿到返回結果後就會執行 handler 函數，對返回的數據進行處理。
我們使用 jquery 向服務端發送一個 JSONP 格式的請求，從瀏覽器控制台可以看到請求和對應的響應，如下圖所示：
JSONP請求
JSONP請求的響應
由上圖可以看到，發送JSONP請求時，請求的 Type 為 script 類型而非 xhr 類型，這樣就打破了跨域報錯的三個必要條件，不會產生跨域錯誤，同時也驗證了服務端返回的數據格式為 javascript 代碼調用的形式，其中 Jquery331045** 這一長串函數名是 jquery 自動生成的。
由於 JSONP 的原理是使用 script 標簽來載入數據，所以它的相容性很好，但是使用 JSONP 來解決跨域問題存在以下缺陷：
- 只能發送 GET 請求
- 發送的不是 XHR 請求，這樣導致 XHR 請求中的很多事件都無法進行處理
- 服務端需要改動
3.3 跨域資源共用CORS
CORS 是一個 W3C 標準，全稱是"跨域資源共用"（Cross-origin resource sharing）。它允許瀏覽器向跨源伺服器，發出 XMLHttpRequest 請求，從而剋服了 AJAX 只能同源使用的限制。CORS 基於 http 協議關於跨域方面的規定，使用時，客戶端瀏覽器直接非同步請求被調用端服務端，在響應頭增加響應的欄位，告訴瀏覽器後臺允許跨域。
跨域錯誤
回到文章開始的這個跨域錯誤信息，可以看到錯誤的具體信息是：服務端沒有設置Access-Control-Allow-Origin 這個響應頭從而導致報錯，通過設置 Access-Control-Allow-Origin: * 這個響應頭，我們可以解決問題。但是，這種設置能滿足所有情況嗎？ 更進一步，使用 CORS 時瀏覽器如何檢查跨域錯誤？ 前面我們有講到，雖然瀏覽器報錯，但是在這之前服務端已經接受了請求，那麼，瀏覽器總是先發出請求後再進行判斷嗎？下麵我們一一討論。
3.3.1 瀏覽器如何檢查跨域錯誤
瀏覽器檢查跨域錯誤的基本原理是：
瀏覽器檢測到 ajax 請求的域與當前域不一致，會在請求頭中增加 Origin 欄位，然後檢查服務端響應頭 Access-Control-Allow-Origin，如果不存在或不匹配，則報跨域錯誤。
瀏覽器檢查跨域錯誤原理
3.3.2 瀏覽器總是先發出請求，然後根據是否有 Access-Control-Allow-Origin 響應頭來判斷嗎
答案是，對於簡單請求，是；而對於非簡單請求，不是。非簡單請求的情況下，瀏覽器並不是直接請求所需資源，而是會先發出一個預檢請求，預檢請求通過後才會對所需資源進行請求。
非簡單請求預檢請求
這裡涉及到的簡單請求和非簡單請求的概念，那麼簡單請求和非簡單請求有什麼區別呢？MDN 對非簡單請求進行了定義，滿足下列條件之一，即為非簡單請求：
- 使用了下列 HTTP 方法：PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH
- 使用了除以下首部之外的其他首部：Accept、Accept-Language、Content-Language、Content-Type
- Content-Type首部的值不屬於下列其中一個： application/x-www-form-urlencoded、 multipart/form-data、 text/plain
- 請求中的 XMLHttpRequestUpload 對象註冊了任意多個事件監聽器
- 請求中使用了ReadableStream對象
簡單來說，除了我們平時使用最多的 GET 和 POST 方法，以及最常使用的 Accept、Accept-Language、Content-Language 和 類型為 application/x-www-form-urlencoded、 multipart/form-data、 text/plain 的 Content-Type 請求頭，其他基本都是非簡單請求。對於這些非簡單請求，瀏覽器會發出兩個請求，第一個為 OPTIONS 遇見請求，遇見請求的響應檢查通過後才會發出對資源的請求。
非簡單請求過程
生產環境下，如果需要發送非簡單跨域請求，每次兩個請求會增加響應時間，為此，W3C 標準中增加了另一個響應頭 Access-Control-Max-Age 參數，該響應頭表明瞭對於非簡單請求的預檢請求瀏覽器的緩存時間，在緩存有效期內，非簡單請求可以不發送預檢請求，另外，實際開發中，可以在服務端設置接收到的請求方法是 OPTIONS 時，直接返回 200，這樣也能加快響應。
3.3.3 設置 Access-Control-Allow-Origin: * 就行嗎
帶cookie的跨域
當我們需要發送帶 cookie 的請求時，Access-Control-Allow-Origin 直接設置為通配符 * 時是無法通過瀏覽器的檢查的，此時該響應頭的值必須與發出請求的域完全匹配才行，另外，還需要設置 Access-Control-Allow-Credentials 響應頭的值為 true，表示支持帶 cookie 的跨域請求。
3.3.4 CORS請求頭和響應頭總結
請求頭：
- Origin： 瀏覽器發出 Ajax 跨域請求之前會添加此頭部，值為發送請求的域
- Access-Control-Request-Method：使用了除 GET、POST 請求方法之外的方法，瀏覽器會添加此頭部，值為當前請求方法
- Access-Control-Request-Headers：使用了自定義頭部或除了Accept、Accept-Language、Content-Language、Content-Type 之外的頭部，瀏覽器會添加此頭部，值為當前的請求方法
響應頭：
- Access-Control-Allow-Origin： 表示服務端允許哪些域請求資源
- Access-Control-Allow-Methods： 當客戶端包含 Access-Control-Request-Method 請求頭時，服務端需要響應該頭部，值通常由 Reauest 的 header 中 Access-Control-Request-Method 取得
- Access-Control-Allow-Headers： 當客戶端包含 Access-Control-Request-Headers 請求頭時，服務端需要響應該頭部，值通常由 Reauest 的 header 中 Access-Control-Request-Headers 取得
- Access-Control-Expose-Headers： 指出客戶端通過 XHR 對象的 getResponseHeaders 方法可以獲取的響應頭有哪些
- Access-Control-Allow-Credentials： 允許帶 cookie 的跨域請求
- Access-Control-Max-Age： 預檢請求的緩存時間
4. 總結
本文介紹了跨域的原因，重點介紹了使用 JSONP 和 CORS 解決跨域問題的方法。除此之外，實際開發中還其他各種解決跨域問題的思路，本質上，這些方法都是打破跨域錯誤的三個條件，大家可以自行查資料瞭解一下。
此文已由作者授權騰訊雲+社區在各渠道發佈
搜索關註公眾號「雲加社區」，第一時間獲取技術乾貨，關註後回覆1024 送你一份技術課程大禮包！
