談談CORS那點事

前端開發過程當中經常須要進行跨域請求 說跨域 有個名詞來簡單瞭解下 "同源策略"html

同源策略:限制從一個源加載的文檔或腳本如何與來自另外一個源的資源進行交互。這是一個用於隔離潛在惡意文件的關鍵的安全機制。前端

若是協議,端口(若是指定了一個)和域名對於兩個頁面是相同的,則兩個頁面具備相同的源。api

下表給出了相對baidu.com/dir/page.ht…:跨域

  1. (同協議 同域名) baidu.com/dir/page1.h… 同 源
  2. (不一樣協議) baidu.com/dir/page1.h… 不一樣源
  3. (不一樣端口) baidu.com:81/dir/page1.h… 不一樣源
  4. (不一樣域名) baidu2.com/dir/page.ht… 不一樣源

跨域就跟在本身(同源)的家 同樣想幹啥就幹啥 能夠別人家(不一樣源)就不行了
這時候我就想要訪問不一樣源的 以往的幹法是
JSONP是能夠實現的 可是有幾個很差的地方瀏覽器

  1. JSONP只能實現GET請求
  2. JSONP被老的瀏覽器支持

這個時候cors出現了
CORS:跨域資源共享(CORS )是一種網絡瀏覽器的技術規範,它爲Web服務器定義了一種方式,容許網頁從不一樣的域訪問其資源。而這種訪問是被同源策略所禁止的。CORS系統定義了一種瀏覽器和服務器交互的方式來肯定是否容許跨域請求。 它是一個妥協,有更大的靈活性,但比起簡單地容許全部這些的要求來講更加安全。安全

因此按照這麼說 這CORS就是一種規範 只有基於這個規範 按照規矩來就能夠實現不一樣源之間資源訪問bash

各主流的瀏覽器都會對動態的跨域請求進行特殊的驗證處理。驗證處理分爲簡單請求驗證處理和預先請求驗證處理。服務器

簡單請求:
當請求同時知足下面兩個條件時候cookie

請求方法是下列之一:網絡

  • GET
  • HEAD
  • POST

請求頭中的Content-Type請求頭的值是下列之一:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

簡單請求時候 瀏覽器會直接發送跨域請求在請求頭中攜帶Origin的header代表這是一個跨域的請求。服務器端接到請求後,會根據本身的跨域規則,經過Access-Control-Allow-Origin和Access-Control-Allow-Methods響應頭,來返回驗證結果。

Access-Control-Allow-Origin: http://XXX.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8複製代碼

這裏是容許訪問後服務器響應
來解釋下

  • Access-Control-Allow-Origin: 要麼指定 origin值 要麼就是* 表示接受任意域名請求
  • Access-Control-Allow-Credentials: 該字段可選。它的值是一個布爾值,表示是否容許發送Cookie。默認狀況下,Cookie不包括在CORS請求之中。設爲true,即表示服務器明確許可,Cookie能夠包含在請求中,一塊兒發給服務器。這個值也只能設爲true,若是服務器不要瀏覽器發送Cookie,刪除該字段便可。

若是要發送Cookie,Access-Control-Allow-Origin就不能設爲星號,必須指定明確的、與請求網頁一致的域名。同時,Cookie依然遵循同源政策,只有用服務器域名設置的Cookie纔會上傳,其餘域名的Cookie並不會上傳,且(跨源)原網頁代碼中的document.cookie也沒法讀取服務器域名下的Cookie。

預先請求
當請求同時知足下面兩個條件時候

請求方法不是下列之一:

  • GET
  • HEAD
  • POST

請求頭中的Content-Type請求頭的值不是下列之一:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

預先請求 瀏覽器先詢問服務器,當前網頁所在的域名是否在服務器的許可名單之中,以及可使用哪些HTTP動詞和頭信息字段。只有獲得確定答覆,瀏覽器纔會發出正式的XMLHttpRequest請求,不然就報錯。

下面是預先請求的HTTP頭信息

OPTIONS /cors HTTP/1.1
Origin: http://xxx.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,表示請求來自哪一個源。
上面預先請求中

  • Access-Control-Request-Method: 表示請求的用到那個HTTP方法
  • Access-Control-Request-Headers:該字段是一個逗號分隔的字符串,指定瀏覽器CORS請求會額外發送的頭信息字段,上例是X-Custom-Header。

下面是預先請求響應

Access-Control-Allow-Origin: http://xxx.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header複製代碼
  • Access-Control-Allow-Origin:表示xxx.com能夠請求數據。該字段也能夠設爲星號,表示贊成任意跨源請求。

一旦服務器經過了"預檢"請求,之後每次瀏覽器正常的CORS請求,就都跟簡單請求同樣,會有一個Origin頭信息字段。服務器的迴應,也都會有一個Access-Control-Allow-Origin頭信息字段。

參考連接: 跨域資源共享 CORS 詳解

相關文章
相關標籤/搜索