2. 程式人生 > >徹底理解CORS跨域原理

徹底理解CORS跨域原理

阿新 • • 發佈：2019-10-10

背景

現在的前端開發中都是前後端分離的開發模式，資料的獲取並非同源，所以跨域的問題在我們日常開發中特別常見。其實這種資料網上也是一搜一大堆，但是都不夠全面，理解起來也不夠透徹。這篇文章就結合具體的示例程式碼以及之前分享的PPT進行整合將跨域的原理梳理一遍。

跨域的基本概念

什麼是跨域，什麼時候產生跨域，相信大家都是知道的。咱們這裡就長話短說了。

不要覺得我誇張了，我是為了強調，強調，強調！！!^_^

瀏覽器為了一定的安全因素，增加了同源策略。有違同源策略的操作都是被禁止的，這個時候就會發生我們所說的跨域。如果沒有同源策略會怎樣？這就好玩了。

誒，請求發出去了，資料沒回來。**

廣義的跨域

其實瀏覽器載入的資源很多都是跨域的，只是有些資源的載入瀏覽器是允許的。

圖片、CSS、Script等資源是不受同源策略限制的。

狹義的跨域

我們所說的跨域主要說的是ajax請求無法完成。

跨域解決方案

跨域解決方案有很多了，能搜出一堆。不過也只有幾個是常用的。有些方案可以瞭解下看看是怎麼回事就可以了。

古老的JSONP

JSONP的優點就是因為他夠老，能相容各種瀏覽器，無相容問題，眾生平等。

他傳送的不是ajax請求，而是利用了script標籤載入機制。他傳送的不是ajax請求。

一圖勝過千言啊。

既然機制我們已經瞭解了。那咱們看下具體的實現。

客戶端程式碼


function jsonp() {
    var script = document.createElement('script');
    script.type = 'text/javascript';

    // 傳參並指定回撥執行函式為backFn
    script.src = 'http://localhost:8100/getUserInfo?uid=100&callback=backFn';
    document.head.appendChild(script);
}

// 回撥執行函式
function backFn(res) {
    alert(JSON.stringify(res));
}

document.getElementById('btn_get_data').addEventListener('click',()=>{
    jsonp();
});

服務端程式碼

let uid = ctx.query.uid;
let callback=ctx.query.callback;
ctx.body = 'backFn({"code": 0, "user": "admin"})';

程式碼很簡單，就不多說了。

JSONP缺點

只支援get，而且存在安全問題。

技術發展至今，jsonp這種前後端耦合的方式肯定要被代替。

CORS跨域解決方案

2014年1月16號CORS作為http協議的擴充部分正式釋出，主要定義了客戶端和服務端的溝通機制，也就是所謂的協議。

看圖加深理解

CORS從具體的程式碼實現上來說比較方便，前端幾乎不需要寫任何程式碼就可以支援。主要是靠服務端進行配置。而且是對各種請求方法、各種資料請求型別都是完美支援的。

CORS需要瀏覽器和伺服器同時支援。目前所有瀏覽器都支援該功能，IE瀏覽器不能低於IE10。

整個CORS通訊過程，都是瀏覽器自動完成，不需要使用者參與。對於開發者來說，CORS通訊與同源的AJAX通訊沒有差別，程式碼完全一樣。瀏覽器一旦發現AJAX請求跨源，就會自動新增一些附加的頭資訊，有時還會多出一次附加的請求，但使用者不會有感覺。

因此，實現CORS通訊的關鍵是伺服器。只要伺服器實現了CORS介面，就可以跨源通訊。

CORS的兩種請求

瀏覽器將CORS請求分成兩類：簡單請求（simple request）和非簡單請求（預檢請求）（not-so-simple request）。

只要同時滿足以下兩大條件，就屬於簡單請求。

(1) 請求方法是以下三種方法之一：

HEAD
GET
POST

(2)HTTP請求頭資訊不超出以下幾種欄位：

Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain

凡是不同時滿足上面兩個條件，就屬於非簡單請求。

瀏覽器對這兩種請求的處理，是不一樣的。

CORS的簡單請求

對於簡單請求，瀏覽器直接發出CORS請求。具體來說，就是在頭資訊之中，增加一個Origin欄位。

下面是一個例子，瀏覽器發現這次跨源AJAX請求是簡單請求，就自動在頭資訊之中，新增一個Origin欄位。

GET /cors HTTP/1.1 
Origin: http://m.xin.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面的頭資訊中，Origin欄位用來說明，本次請求來自哪個源（協議 + 域名 + 埠）。伺服器根據這個值，決定是否同意這次請求。

如果Origin指定的源，不在許可範圍內，伺服器會返回一個正常的HTTP迴應。瀏覽器發現，這個迴應的頭資訊沒有包含Access-Control-Allow-Origin欄位（詳見下文），就知道出錯了，從而丟擲一個錯誤，被XMLHttpRequest的onerror回撥函式捕獲。注意，這種錯誤無法通過狀態碼識別，因為HTTP迴應的狀態碼有可能是200。

如果Origin指定的域名在許可範圍內，伺服器返回的響應，會多出幾個頭資訊欄位。

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

上面的頭資訊之中，有三個與CORS請求相關的欄位，都以Access-Control-開頭。

（1）Access-Control-Allow-Origin

該欄位是必須的。它的值要麼是請求時Origin欄位的值，要麼是一個*，表示接受任意域名的請求。

（2）Access-Control-Allow-Credentials

該欄位可選。它的值是一個布林值，表示是否允許傳送Cookie。預設情況下，Cookie不包括在CORS請求之中。設為true，即表示伺服器明確許可，Cookie可以包含在請求中，一起發給伺服器。這個值也只能設為true，如果伺服器不要瀏覽器傳送Cookie，刪除該欄位即可。

（3）Access-Control-Expose-Headers

該欄位可選。CORS請求時，XMLHttpRequest物件的getResponseHeader()方法只能拿到6個基本欄位：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他欄位，就必須在Access-Control-Expose-Headers裡面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar欄位的值。

withCredentials 屬性

上面說到，CORS請求預設不傳送Cookie和HTTP認證資訊。如果要把Cookie發到伺服器，一方面要伺服器同意，指定Access-Control-Allow-Credentials欄位。

Access-Control-Allow-Credentials: true

另一方面，開發者必須在AJAX請求中開啟withCredentials屬性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否則，即使伺服器同意傳送Cookie，瀏覽器也不會發送。或者，伺服器要求設定Cookie，瀏覽器也不會處理。

但是，如果省略withCredentials設定，有的瀏覽器還是會一起傳送Cookie。這時，可以顯式關閉withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要傳送Cookie，Access-Control-Allow-Origin就不能設為星號，必須指定明確的、與請求網頁一致的域名。同時，Cookie依然遵循同源政策，只有用伺服器域名設定的Cookie才會上傳，其他域名的Cookie並不會上傳，且（跨源）原網頁程式碼中的document.cookie也無法讀取伺服器域名下的Cookie。

CORS簡單請求程式碼參考

簡單請求客戶端不需要做什麼處理，這裡只展示服務端需要做的處理。

服務端程式碼使用Node koa編寫

    ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
            ctx.set('Access-Control-Allow-Credentials','true');
            body.data={
                carId:100,
                carName:'寶馬x5-1000'
            };

另外關於cookie的傳遞大家可以自己試試

CORS非簡單請求-預檢請求

非簡單請求是那種對伺服器有特殊要求的請求，比如請求方法是PUT或DELETE，或者Content-Type欄位的型別是application/json。

非簡單請求的CORS請求，會在正式通訊之前，增加一次HTTP查詢請求，稱為"預檢"請求（preflight）。

瀏覽器先詢問伺服器，當前網頁所在的域名是否在伺服器的許可名單之中，以及可以使用哪些HTTP動詞和頭資訊欄位。只有得到肯定答覆，瀏覽器才會發出正式的XMLHttpRequest請求，否則就報錯。

看圖理解

下面是一段瀏覽器的JavaScript指令碼。

var url = 'http://api.uxin.com/user';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

上面程式碼中，HTTP請求的方法是PUT，並且傳送一個自定義頭資訊X-Custom-Header。

瀏覽器發現，這是一個非簡單請求，就自動發出一個"預檢"請求，要求伺服器確認可以這樣請求。下面是這個"預檢"請求的HTTP頭資訊。

OPTIONS /cors HTTP/1.1
Origin: http://m.a.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

"預檢"請求用的請求方法是OPTIONS，表示這個請求是用來詢問的。頭資訊裡面，關鍵欄位是Origin，表示請求來自哪個源。

除了Origin欄位，"預檢"請求的頭資訊包括兩個特殊欄位。

（1）Access-Control-Request-Method

該欄位是必須的，用來列出瀏覽器的CORS請求會用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

該欄位是一個逗號分隔的字串，指定瀏覽器CORS請求會額外發送的頭資訊欄位，上例是X-Custom-Header。

CORS預檢請求的響應

伺服器收到"預檢"請求以後，檢查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers欄位以後，確認允許跨源請求，就可以做出迴應。

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://m.a.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

上面的HTTP迴應中，關鍵的是Access-Control-Allow-Origin欄位，表示http://m.a.com可以請求資料。該欄位也可以設為星號，表示同意任意跨源請求。

Access-Control-Allow-Origin: *

如果瀏覽器否定了"預檢"請求，會返回一個正常的HTTP迴應，但是沒有任何CORS相關的頭資訊欄位。這時瀏覽器就會認定，伺服器不同意預檢請求，因此觸發一個錯誤，被XMLHttpRequest物件的onerror回撥函式捕獲。控制檯會打印出如下的報錯資訊。

XMLHttpRequest cannot load http://m.a.com.
Origin http://m.a.com is not allowed by Access-Control-Allow-Origin.

伺服器迴應的其他CORS相關欄位如下。

Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000

（1）Access-Control-Allow-Methods

該欄位必需，它的值是逗號分隔的一個字串，表明伺服器支援的所有跨域請求的方法。注意，返回的是所有支援的方法，而不單是瀏覽器請求的那個方法。這是為了避免多次"預檢"請求。

（2）Access-Control-Allow-Headers

如果瀏覽器請求包括Access-Control-Request-Headers欄位，則Access-Control-Allow-Headers欄位是必需的。它也是一個逗號分隔的字串，表明伺服器支援的所有頭資訊欄位，不限於瀏覽器在"預檢"中請求的欄位。

（3）Access-Control-Allow-Credentials

該欄位與簡單請求時的含義相同。

（4）Access-Control-Max-Age

該欄位可選，用來指定本次預檢請求的有效期，單位為秒。上面結果中，有效期是20天（1728000秒），即允許快取該條迴應1728000秒（即20天），在此期間，不用發出另一條預檢請求。

CORS瀏覽器的正常請求和迴應

一旦伺服器通過了"預檢"請求，以後每次瀏覽器正常的CORS請求，就都跟簡單請求一樣，會有一個Origin頭資訊欄位。伺服器的迴應，也都會有一個Access-Control-Allow-Origin頭資訊欄位。

下面是"預檢"請求之後，瀏覽器的正常CORS請求。

PUT /cors HTTP/1.1
Origin: http://m.a.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0..

上面頭資訊的Origin欄位是瀏覽器自動新增的。

下面是伺服器正常的迴應。

Access-Control-Allow-Origin: http://m.a.com
Content-Type: text/html; charset=utf-8

上面頭資訊中，Access-Control-Allow-Origin欄位是每次迴應都必定包含的。

CORS預檢請求程式碼參考

程式碼使用Node koa實現

  //OPTIONS 請求查詢伺服器的效能，或者查詢與資源相關的選項和需求
            ctx.set('Access-Control-Allow-Credentials', 'true');
            ctx.set('Access-Control-Allow-Methods','PUT');
            ctx.set('Access-Control-Allow-Origin', 'http://localhost:3000');
            ctx.set('Access-Control-Allow-Headers', 'content-type');
            ctx.set('Access-Control-Max-Age','100');
            body.data = {
                carId: 100,
                carName: '寶馬x5'
            }

CORS相容情況

CORS支援IE10+，IE8，9需要使用ie獨有的api - 使用XDomainRequest物件來支援 cors。

注意：ie下 localhost:8000=localhost:8001=localhost 視為同域，以免本地進行測試的時候踩坑。

CORS總結

我們要知道CORS是http協議的一部分，由瀏覽器和伺服器來完成。所以對於前端來說還是比較簡單的。我們要做的是理解這個協議和實現機制，在遇到類似問題的時候可以快速的定位。

更多跨域處理方案

跨域解決辦法很多，最常用的莫過於CORS。上圖這7種有興趣的同學可以繼續研究。

參考資料

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS

https://segmentfault.com/a/1190000011145364

http://www.ruanyifeng.com/blog/2016/04/cors.

相關推薦

徹底理解CORS跨域原理

背景 現在的前端開發中都是前後端分離的開發模式，資料的獲取並非同源，所以跨域的問題在我們日常開發中特別常見。其實這種資料網上也是一搜一大堆，但是都不夠全面，理解起來也不夠透徹。這篇文章就結合具體的示例程式碼以及之前分享的PPT進行整合將跨域的原理梳理一遍。 跨域的基本概念 什麼是跨域，什麼時候產生跨域，相信大

關於CORS跨域問題的理解

當前 get 說明 multipart 服務 tom HP gin 範圍 起因 因為這段時間一個項目前後端分別部署在不同服務器的需要,抽空學習了一下CORS問題,不足之處,歡迎指教. 什麽是CORS CORS是一個w3c標準,全稱是"跨域資源共享"(Cross-orig

深入理解前端跨域方法和原理

前言 受瀏覽器同源策略的限制，本域的js不能操作其他域的頁面物件（比如DOM）。但在安全限制的同時也給注入iframe或是ajax應用上帶來了不少麻煩。所以我們要通過一些方法使本域的js能夠操作其他域的頁面物件或者使其他域的js能操作本域的頁面物件（iframe之間）

CORS——跨域請求那些事兒

lob 有效期 site cati 項目 light 另一個 send 決定 在日常的項目開發時會不可避免的需要進行跨域操作，而在實際進行跨域請求時，經常會遇到類似 No ‘Access-Control-Allow-Origin‘ header is present on

cors跨域問題

sco vs2015 不能 allow 並不會 name config 狀態 添加 這兩天公司布置一個特別簡單的管理系統，增刪查改四個接口，前端使用技術（html/css/angularjs），後臺（c#/mvc），數據庫（mysql） 前端寫完，後臺寫完，在交互的時候就遇

CORS跨域請求總結

eve log 那種 http lencod pos 方法 ref orm CORS跨域請求分為簡單請求和復雜請求。 1. 簡單請求： 滿足一下兩個條件的請求。 （1) 請求方法是以下三種方法之一： HEAD GET POST （2）HTTP的頭信息不超出以下幾種字段：

CORS跨域資源共享你該知道的事兒

自身 沒有 對象的使用方法 one 一起 接受 gpm spa eat “嘮嗑之前，一些客套話” CORS跨域資源共享，這個話題大家一定不陌生了，吃久了大轉轉公眾號的深度技術好文，也該吃點兒小米粥溜溜胃裏的縫兒了，今天咱們就再好好屢屢CORS跨域資源共享這個話題，大牛怡情

前端-關於CORS跨域的解決方案，面向服務端

red 瀏覽器 環境 和我 methods retrieve name 後臺 一件事 最近自己在寫後臺管理系統的時候，並沒有采用jsp、freemaker、葉子等模板技術，而是由後端提供數據api，前端通過AJAX和JQuery來動態操作頁面上的一些div、table元素，

Java實現CORS跨域請求

先來 pty contain type 資源共享 服務端 header req options 問題 使用前後端分離模式開發項目時，往往會遇到這樣一個問題 -- 無法跨域獲取服務端數據 這是由於瀏覽器的同源策略導致的，目的是為了安全。在前後端分離開發模式備受青睞的今天，前

CORS 跨域請求

seh ces .html set zip 同時 頭信息 agent client 一、簡介 CORS需要瀏覽器和服務器同時支持。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低於IE10。 整個CORS通信過程，都是瀏覽器自動完成，不需要用戶參與。對於開發者來說，CORS通

spring boot Cors 跨域

-a control app ppi map ring als cor spring 在訪問web工程的時候，經常會報一些跨域的錯誤：CORS header ‘Access-Control-Allow-Origin’ missingspring boot中的cors設定方式

Ajax跨域原理及解決方案

一次 變化 mes iframe 實現 type .ajax 一個 min 跨域請求的產生 跨域請求歸根結底是由於瀏覽器的“同源策略”引起的，同源策略指的是域名相同、協議相同、端口相同， 假設有http://www.a.com/test.html，下面的示例 域名不同 h

CORS跨域請求：前後端分離

跨域 請求過濾器： /** * OncePerRequestFilter保證在任何Servlet容器中都是一個請求只執行一次的過濾器。 */ public class CorsFilter extends OncePerRequestFilter { @Override protected void do

理解瀏覽器跨域

1.跨域是怎麼產生的? 瀏覽器的同源策略規定預設情況下，JavaScript在傳送AJAX請求時，URL的域名必須和當前頁面完全一致。 域名要相同（mp.csdn.com和mp.csdn2.com不同），協議要相同（http和https不同），埠號要相同（80埠和:8080就不同）. 同

CORS 跨域與 TP5中跨域的解決方案

在做專案過程中,使用Vue-element-admin作為前端,ThinkPHP5作為後端框架進行開發,會遭遇跨域問題,本文給出ThinkPHP5解決跨域 1.CORS的概念     CORS（Cross-Origin Resource Sharing 跨源資源共享），當

cors跨域請求問題 關於spring -springmvc -mybatis .基於xml配置方式

1:場景還原     今天要寫一個方法, 需求是  在購物車服務上,  呼叫一個個人中心的方法 ,用到了 跨域請求.      我就在個人中心的 上面寫了個方法, 並在springMVC.xml中,配置了    &

Shiro框架在CORS跨域訪問中遇到的問題及解決

背景 最近做一個前後端分離的專案時,使用shiro做許可權管理時遇到跨域問題，這裡做一下記錄。   原因 後端通過Shiro配置URL過濾, shiroFilterFactoryBean.setLoginUrl("/unauth"); 預設對於沒有授權的訪問

CORS跨域與Nginx反向代理

最近的專案都是關於前後端分離的，當我們把專案橫向分層前後端分離後，由於瀏覽器安全限制會發現請求出現異常，主要原因是瀏覽器的同源策略（協議、域名和埠）是否相同。 解決方案： 解決跨域的方法有很多，如 (1)通過jsonp跨域 (2)通過修改document.domain來跨子域 (3)

深入剖析jsonp跨域原理

專案中遇到一個jsonp跨域的問題，於是仔細的研究了一番jsonp跨域的原理。搞明白了一些以前不是很懂的地方，比如： 1）jsonp跨域只能是get請求，而不能是post請求； 2）jsonp跨域的原理到底是什麼； 3）除了jsonp跨域之外還有那些方法繞過“同源策略”，實現跨域

Spring Boot Web應用開發 CORS 跨域請求設定 Invalid CORS request

使用SpringBoot Web開發程式時，前後端分離時，經常遇到跨域問題，特別是很多情況下Firefox瀏覽器沒有問題，而chrome瀏覽器有問題，僅僅從瀏覽器的web控制檯很難發現有效的錯誤或者告警資訊，因此在開發程式很有必要在開發階段就考慮到並配置好跨域。 SpringBoot