web開發的跨域問題詳解

騰訊雲加社群發表於2018-12-28
Web跨域

本文由雲+社群發表

做過 web 開發的同學，應該都遇到過跨域的問題，當我們從一個域名向另一個域名傳送 Ajax 請求的時候，開啟瀏覽器控制檯就會看到跨域錯誤，今天我們就來聊聊跨域的問題。

1. 瀏覽器的同源策略

同源的定義是：如果兩個頁面的***協議***，*埠*（如果有指定）和***域名都相同，則兩個頁面具有相同的源*。同源策略限制了從同一個源載入的文件或指令碼如何與來自另一個源的資源進行互動。這是一個用於隔離潛在惡意檔案的重要安全機制。

2. 跨域錯誤資訊產生的原因

為了說明問題，我們可以做如下實驗，我們在本地搭建了開發環境， 由客戶端 http://localhost:3001 向伺服器 http://localhost:3000 傳送兩個請求，一個使用 javascript 非同步請求資料，另一個使用 img 標籤請求資料，伺服器收到請求後，列印接收到請求的日誌，如下圖所示：

img
客戶端傳送兩個請求

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 瀏覽器的安全檢查功能，同時也會禁用跨域安全檢查功能，這樣再次拿前面的例子進行測試，發現此時不會報錯，同時也可以正確拿到服務端返回的資料。

img
禁用瀏覽器安全檢查功能

這種方式雖然可以實現跨域，但是需要每個使用者都對瀏覽器進行設定，同時可能導致潛在的安全隱患，正常情況下不實用。但這個例子充分說明了，跨域錯誤是前端瀏覽器所做的限制，與後臺服務無關。

3.2 JSONP實現跨域

根據思路2，既然跨域問題產生的原因是因為客戶端傳送了 Ajax 請求，那麼我們打破這個條件即可。具體實現方式就是使用 JSONP 來進行跨域請求。

JSONP，是 JSON with Padding 的簡稱，它是 json 的一種補充使用方式，利用 script 標籤來解決跨域問題。JSONP 是非官方協議，他只是前後端一個約定，如果請求引數帶有約定的引數，則後臺返回 javascript 程式碼而非 json 資料，返回程式碼是函式呼叫形式，函式名即約定值，函式引數即要返回的資料。
複製程式碼

JSONP 的實現原理如下圖所示：

img
JSONP實現原理

首先在客戶端 js 中定義一個函式（假設名為 handler），然後動態建立一個 script 標籤插入頁面中，script 標籤的 src 屬性即要呼叫的地址，同時，在呼叫的 url 中加入一個服務端約定的引數（假設名為 callback，引數值為已定義的函式名 handler），服務端收到請求，如果發現請求的 url 中帶有約定的引數，那麼就返回一段函式呼叫形式的 javascript 程式碼，該段程式碼的函式名即為 callback 引數的值 handler，函式的引數即為待返回的資料。這樣，客戶端拿到返回結果後就會執行 handler 函式，對返回的資料進行處理。

我們使用 jquery 向服務端傳送一個 JSONP 格式的請求，從瀏覽器控制檯可以看到請求和對應的響應，如下圖所示：

img
JSONP請求

img
JSONP請求的響應

由上圖可以看到，傳送JSONP請求時，請求的 Type 為 script 型別而非 xhr 型別，這樣就打破了跨域報錯的三個必要條件，不會產生跨域錯誤，同時也驗證了服務端返回的資料格式為 javascript 程式碼呼叫的形式，其中 Jquery331045** 這一長串函式名是 jquery 自動生成的。

由於 JSONP 的原理是使用 script 標籤來載入資料，所以它的相容性很好，但是使用 JSONP 來解決跨域問題存在以下缺陷：

  1. 只能傳送 GET 請求
  2. 傳送的不是 XHR 請求，這樣導致 XHR 請求中的很多事件都無法進行處理
  3. 服務端需要改動

3.3 跨域資源共享CORS

CORS 是一個 W3C 標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。它允許瀏覽器向跨源伺服器，發出 XMLHttpRequest 請求，從而克服了 AJAX 只能同源使用的限制。CORS 基於 http 協議關於跨域方面的規定，使用時，客戶端瀏覽器直接非同步請求被呼叫端服務端，在響應頭增加響應的欄位，告訴瀏覽器後臺允許跨域。

img
跨域錯誤

回到文章開始的這個跨域錯誤資訊，可以看到錯誤的具體資訊是：服務端沒有設定Access-Control-Allow-Origin 這個響應頭從而導致報錯，通過設定 Access-Control-Allow-Origin: * 這個響應頭，我們可以解決問題。但是，這種設定能滿足所有情況嗎？ 更進一步，使用 CORS 時瀏覽器如何檢查跨域錯誤？ 前面我們有講到，雖然瀏覽器報錯，但是在這之前服務端已經接受了請求，那麼，瀏覽器總是先發出請求後再進行判斷嗎？下面我們一一討論。

3.3.1 瀏覽器如何檢查跨域錯誤

瀏覽器檢查跨域錯誤的基本原理是：

瀏覽器檢測到 ajax 請求的域與當前域不一致，會在請求頭中增加 Origin 欄位，然後檢查服務端響應頭 Access-Control-Allow-Origin，如果不存在或不匹配，則報跨域錯誤。
複製程式碼

img
瀏覽器檢查跨域錯誤原理

3.3.2 瀏覽器總是先發出請求，然後根據是否有 Access-Control-Allow-Origin 響應頭來判斷嗎

答案是，對於簡單請求，是；而對於非簡單請求，不是。非簡單請求的情況下，瀏覽器並不是直接請求所需資源，而是會先發出一個預檢請求，預檢請求通過後才會對所需資源進行請求。

img
非簡單請求預檢請求

這裡涉及到的簡單請求和非簡單請求的概念，那麼簡單請求和非簡單請求有什麼區別呢？MDN 對非簡單請求進行了定義，滿足下列條件之一，即為非簡單請求：

  1. 使用了下列 HTTP 方法：PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH
  2. 使用了除以下首部之外的其他首部：Accept、Accept-Language、Content-Language、Content-Type
  3. Content-Type首部的值不屬於下列其中一個： application/x-www-form-urlencoded、 multipart/form-data、 text/plain
  4. 請求中的 XMLHttpRequestUpload 物件註冊了任意多個事件監聽器
  5. 請求中使用了ReadableStream物件

簡單來說，除了我們平時使用最多的 GET 和 POST 方法，以及最常使用的 Accept、Accept-Language、Content-Language 和 型別為 application/x-www-form-urlencoded、 multipart/form-data、 text/plain 的 Content-Type 請求頭，其他基本都是非簡單請求。對於這些非簡單請求，瀏覽器會發出兩個請求，第一個為 OPTIONS 遇見請求，遇見請求的響應檢查通過後才會發出對資源的請求。

img
非簡單請求過程

生產環境下，如果需要傳送非簡單跨域請求，每次兩個請求會增加響應時間，為此，W3C 標準中增加了另一個響應頭 Access-Control-Max-Age 引數，該響應頭表明了對於非簡單請求的預檢請求瀏覽器的快取時間，在快取有效期內，非簡單請求可以不傳送預檢請求，另外，實際開發中，可以在服務端設定接收到的請求方法是 OPTIONS 時，直接返回 200，這樣也能加快響應。

3.3.3 設定 Access-Control-Allow-Origin: * 就行嗎

img
帶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 送你一份技術課程大禮包！

相關文章