HTTP訪問控制（CORS）知識梳理

Web 開發者必需要要知道的知識，怎麼處理去處理跨域訪問資源。很早以前就知道怎麼去處理跨域，好比jsonp，也知道今天準備梳理的知識：跨域資源共享（CORS），可是尚未認真的去了解這種協議支持那些響應頭，規則是怎麼樣的，只是知道Access-Control-Allow-Origin這個頭部。此次就來梳理一下。

CORS

先從概念入手，根據MDN文檔中，CORS是 Cross-Origin Resource Sharing的縮寫，也就是跨域資源共享。它是經過一些指定的 HTTP頭信息，來協調瀏覽器和服務器之間，怎麼讓一個容許在某個 origin（domain/域）下的 Web 應用，被容許訪問不一樣源服務器上的資源的。

對於同源策略的規則能夠經過文檔來了解。根據 MDN 文檔中的一個標註，能夠注意到，譯者標註 「並不必定是瀏覽器限制了發起跨域請求，也可能跨域請求能夠正常發起，可是返回結果被瀏覽器攔截了。」

跨域資源共享（ CORS ）機制容許 Web 應用服務器進行跨域訪問控制，從而使跨域數據傳輸得以安全進行。現代瀏覽器支持在 API 容器中（例如 XMLHttpRequest 或 Fetch ）使用 CORS，以下降跨域 HTTP 請求所帶來的風險。

經過上面最後一句話，說使用了CORS是下降了跨域HTTP請求的所帶來的風險，就讓我想到之前比價經常使用的jsonp。

因爲jsonp是經過利用<script>元素的這個開放策略，獲取數據的形式如同加載了一個可執行的js代碼。因而這裏就會存在代碼注入的風險，加載的js代碼裏面就可能會包含一些危險的腳本，好比獲取cookie獲得用戶的會話信息。因此通常來講，若是使用jsonp的對象不是本身掌握的網站或者同公司的業務仍是慎重。jsonp還有一個缺點就是隻能使用GET，靈活性就少了點。

整個在網頁中CORS的過程都是由瀏覽器本身去完成的，當與到跨域請求的時候，瀏覽器會去攜帶相應的頭部，因此通常來講CORS通常技術實現的關注點在服務端。

簡單請求和複雜請求

標準新增了一組 HTTP 首部字段，容許服務器聲明哪些源站經過瀏覽器有權限訪問哪些資源。另外，規範要求，對那些可能對服務器數據產生反作用的 HTTP 請求方法（特別是 GET 之外的 HTTP 請求，或者搭配某些 MIME 類型的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知服務端是否容許該跨域請求。

這裏說的簡單請求和複雜請求，在規範裏面是有明確規定的。若是一個請求被歸爲複雜請求那麼它相對與簡單請求會多一次預檢請求。也就是如上所述，會先使用 OPTIONS 方法發起一個請求，服務器會返回支持的請求和一些其餘信息。

看一下這兩種請求的定義，是怎麼區分的。

簡單請求

對於使用 XMLHttpRqeuest 對象來請求，以下場景被認爲是簡單請求：

• 請求方法爲其中幾種：
  • GET
  • HEAD
  • POST
• 請求頭部字段 Content-Type 的值僅限於下列三者之一：
  • text/plain
  • multipart/form-data
  • application/x-www-form-urlencoded

還有兩個須要注意的規定，不是頭部的值，而是對象屬性的設置：

• 請求中的任意XMLHttpRequestUpload 對象均沒有註冊任何事件監聽器；XMLHttpRequestUpload 對象可使用 XMLHttpRequest.upload 屬性訪問。
• 請求中沒有使用 ReadableStream 對象。

如今還有一個比較流行，用來作請求的對象fetch有本身的額外要求：

• Fetch 規範定義了對 CORS 安全的首部字段集合，不得人爲設置該集合以外的其餘首部字段。該集合爲：
  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （須要注意額外的限制）
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width

以上這些請求都會被認爲是簡單請求，也就是不會先使用 OPTIONS 方法去檢查服務器是否支持。排除了以上的請求那就是 複雜請求 了，怪不得有時候會看到 OPTIONS 請求，當時看不懂，不知道爲何。如今知道來源了。

MDN 上有這樣的一個例子：

假如站點 foo.example 的網頁應用想要訪問 bar.other 的資源。foo.example 的網頁中可能包含相似於下面的 JavaScript 代碼：

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/public-data/';
   
function callOtherDomain() {
  if(invocation) {    
    invocation.open('GET', url, true);
    invocation.onreadystatechange = handler;
    invocation.send(); 
  }
}
複製代碼

請求和響應的報文以下：

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://foo.example/examples/access-control/simpleXSInvocation.html
Origin: http://foo.example


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2.0.61 
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[XML Data]
複製代碼

例子中，發起了一個簡單跨域請求，瀏覽器會自動在請求頭部添加了一個字段Origin，來代表發起請求的網站來源哪裏。（我去查了一下，Origin這個字段瀏覽器是拒絕修改的，直接設置這個請求頭是不生效的。）服務端的響應頭部會有一個Access-Control-Allow-Origin字段，來代表資源容許哪些網站訪問，這裏爲*則代表任何網站均可以。

預檢測

當咱們發送不是簡單請求的時候，經過 OPTIONS 先去獲取服務器支持的內容。

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';
    
function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}
複製代碼

來看一下請求頭和響應頭：

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
...


HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
...
複製代碼

OPTIONS 主要是把請求端準備須要使用到的方法等，發送給服務端檢查，是否支持。服務端若是支持，這把相應支持的值所有列出來，注意這裏是所有列出來，是由於避免須要屢次檢查。這裏能夠注意到服務端還有一個字段 Access-Control-Max-Age ，它的值是整數表明多少毫秒，它的做用就是告訴請求者，我返回給你的檢查信息須要多久從新更新一次，也就是從新請求一下。

當預檢查請求有返回對應的字段和值，那麼瀏覽器就會立刻將真實的請求發送出去。若是沒有對應的值，瀏覽器會在控制檯打印相應的錯誤信息，回調 XMLHttpRequest對象的 onerror函數，可是須要注意一點，這時候的狀態碼仍然多是 200， 因此咱們不能經過狀態碼來判斷跨域請求是否成功。

cookie 和 身份認證

通常而言，對於跨域 XMLHttpRequest 或 Fetch 請求，瀏覽器不會發送身份憑證信息。若是要發送憑證信息，須要設置 XMLHttpRequest 的某個特殊標誌位。這個特殊的標誌位 XMLHttpRequest 和 fetch 有點不同。XMLHttpRequest 中是字段 withCredentials，值位 boolean 型，fetch 裏面在請求的時候傳入參數 { credentials: 'include', ...}。有些瀏覽器可能默認是帶 cookie或者認證信息的，針對這種狀況，若是不須要帶的話，能夠將這個字段手動設置爲 false。

想要能帶上這些認證信息，除了請求的時候須要設置 credentials ，服務端也須要在響應頭上設置Access-Control-Allow-Credentials: true，也就是容許攜帶認證信息。若是沒有這值，瀏覽器將不會把響應內容返回給請求的發送者。注意，這裏是數據已經返回可是瀏覽器給攔截了。

有了上訴兩點，還有一個須要規避的狀況（真的是條件多。。。安全問題一大難題），若是服務端將Access-Control-Allow-Origin設置爲*（通配符），請求仍然會失敗，也會被攔截而且拋出異常。

響應字段 和 請求字段

經過上面的描述，大體理清楚了規定和用法，下面列舉一下CORS包含哪些響應字段和請求字段。

響應字段

• Access-Control-Allow-Origin 語法是遮掩的：Access-Control-Allow-Origin: <origin> | *，能夠設置多個 origin ，以逗號隔開就行。 根據語義上理解，就是容許那些 origin 可以訪問資源。

• Access-Control-Expose-Headers 跨域訪問中，請求者通常只能拿到（XMLHttpRequest對象的getResponseHeader()方法）最基本的響應頭，Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma，若是想要拿到其餘響應頭就能夠要服務端設置該頭部。

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
複製代碼

• Access-Control-Max-Age 這個字段以前說過，來代表 預檢查 過時時間，當超過這個時間後，瀏覽器會在複雜請求時會再次使用 OPTIONS 方法獲取支持信息，不然仍是使用上次請求獲取的信息。

• Access-Control-Allow-Credentials 指定請求者是否能攜帶 cookie，其實就是告訴瀏覽器若是請求者帶了 cookie 可是我不須要，瀏覽器你就給它拋一個異常吧，而且當前和你的通訊就不要返回給它了。

Access-Control-Allow-Credentials: true
複製代碼

• Access-Control-Allow-Methods 用於預檢請求的響應。其指明瞭實際請求所容許使用的 HTTP 方法。

Access-Control-Allow-Methods: <method>[, <method>]*
複製代碼

• Access-Control-Allow-Headers 用於預檢請求的響應。其指明瞭實際請求中容許攜帶的首部字段。

Access-Control-Allow-Headers: <field-name>[, <field-name>]*
複製代碼

請求頭部

這些字段無需開發者本身設置，所有有瀏覽器自動帶上。

• Origin 代表請求的來源，有時候這值多是空字符串，文檔中說爲 data URL的時候爲空，我查了一下，data URL是相似於以下請求地址： data:,Hello%2C%20World!簡單的 text/plain 類型數據; data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D上一條示例的 base64 編碼版本; 咱們常見的好比圖片的 base64 的表現形式。

• Access-Control-Request-Method

• Access-Control-Request-Headers 這兩個字段和響應字段是同樣的意思，表示想要支持什麼樣的方法和頭部信息。

小結

梳理了一下 CORS 相關的知識，終於知道有時候發請求的時候一些額外的字段信息是什麼了。我任務 CORS 中這些頭部信息必定須要知道，再之後有一些跨域的狀況，就可讓服務端好好的配合了。

原文地址