web開發的跨域問題詳解

本文由雲+社區發表

作過 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 來解決跨域問題存在如下缺陷：

1. 只能發送 GET 請求
2. 發送的不是 XHR 請求，這樣致使 XHR 請求中的不少事件都沒法進行處理
3. 服務端須要改動

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 對非簡單請求進行了定義，知足下列條件之一，即爲非簡單請求：

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 碰見請求，碰見請求的響應檢查經過後纔會發出對資源的請求。

非簡單請求過程

生產環境下，若是須要發送非簡單跨域請求，每次兩個請求會增長響應時間，爲此，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 解決跨域問題的方法。除此以外，實際開發中還其餘各類解決跨域問題的思路，本質上，這些方法都是打破跨域錯誤的三個條件，你們能夠自行查資料瞭解一下。

此文已由做者受權騰訊雲+社區在各渠道發佈