請求跨域問題詳解

　　在JavaScript中，有一個很重要的安全性限制，被稱為“Same-Origin Policy”（同源策略）。這一策略對於JavaScript代碼能夠訪問的頁面內容做了很重要的限制，即JavaScript只能訪問與包含它的文檔在同一域下的內容。

　　💢跨越是瀏覽器進行安全限制的一種方法，如果瀏覽器禁用了這種安全限制就不會出現跨域問題產生跨域的原因（以下三者都滿足）：

• 只要調用方訪問被調用方的域名、端口、IP不一樣
• 瀏覽器沒有禁用安全限制
• 采用了XMLHttpRequest的請求

　　JavaScript這個安全策略在進行多iframe或多窗口編程、以及Ajax編程時顯得尤為重要。根據這個策略，在baidu.com下的頁面中包含的JavaScript代碼，不能訪問在google.com域名下的頁面內容；甚至不同的子域名之間的頁面也不能通過JavaScript代碼互相訪問。對於Ajax的影響在於，通過XMLHttpRequest實現的Ajax請求，不能向不同的域提交請求，例如，在abc.example.com下的頁面，不能向def.example.com提交Ajax請求，等等。

　　為什么瀏覽器要實現同源限制?我們舉例說明:

　　比如一個黑客,他利用iframe把真正的銀行登錄頁面嵌到他的頁面上,當你使用真實的用戶名和密碼登錄時,如果沒有同源限制,他的頁面就可以通過javascript讀取到你的表單中輸入的內容,這樣用戶名和密碼就輕松到手了。又比如你登錄了OSC,同時瀏覽了惡意網站,如果沒有同源限制,該惡意網站就可以構造AJAX請求頻繁在OSC發廣告帖。

一、跨域問題發生場景

　　

• 特別注意兩點：

　　1、如果是協議和端口造成的跨域問題“前台”是無能為力的

　　2、在跨域問題上，域僅僅是通過“URL的首部”來識別而不會去嘗試判斷相同的ip地址對應着兩個域或兩個域是否在同一個ip上。比如上面的，http://www.a.com/a.js和http://70.32.92.74/b.js。雖然域名和域名的ip對應，不過還是被認為是跨域。

　　*“URL的首部”指window.location.protocol +window.location.host。其中，window.location.protocol：指含有URL第一部分的字符串,如http: ，window.location.host：指包含有URL中主機名:端口號部分的字符串.如//www.cenpok.net/server/

二、跨域問題的解決方案

　　💢解決跨域的思路

• 被調用方解決： 被調用方解決-支持跨域（根據http協議關於跨域方面的要求，增加響應頭信息，告訴瀏覽器允許被跨域調用）（因為在發生跨域請求時首先調用方發送一個預檢請求（OPTIONS請求），這個請求就會被帶上允許跨越的請求頭信息）
• 調用方解決：使用代理做調用解決跨域問題-隱藏跨域（利用nginx的反向代理，使訪問同一個域名不同的資源路徑會代理到不同的服務器上，每個跨域的請求都會帶上origin請求頭字段，因為訪問的資源都是同域名下的，所以不會產生跨越問題）

1、JSONP跨域

​ 　　JSONP（JSON with Padding）是數據格式JSON的一種“使用模式”，可以讓網頁從別的網域要數據。根據 XmlHttpRequest 對象受到同源策略的影響，而利用 <script>元素的這個開放策略，網頁可以得到從其他來源動態產生的JSON數據，而這種使用模式就是所謂的 JSONP。用JSONP抓到的數據並不是JSON，而是任意的JavaScript，用 JavaScript解釋器運行而不是用JSON解析器解析。所有，通過Chrome查看所有JSONP發送的Get請求都是js類型，而非XHR。 

    

①原理

　　我們知道，在頁面上有三種資源是可以與頁面本身不同源的。它們是：js腳本，css樣式文件，圖片，像淘寶等大型網站，肯定會將這些靜態資源放入cdn中，然后在頁面上連接，如下所示，所以它們是可以鏈接訪問到不同源的資源的。

<script type="text/javascript" src="某某cdn地址" ></script>
<link type="text/css" rel="stylesheet" href="某個cdn地址" />
<img src="某個cdn地址" alt=""/>

　　而jsonp就是利用了script標簽的src屬性是沒有跨域的限制的，從而達到跨域訪問的目的。因此它的最基本原理就是：動態添加一個<script>標簽來實現。

②實現方法：

　　這里是使用ajax來請求的，看起來和ajax沒啥區別，其實還是有區別的。ajax的核心是通過XmlHttpRequest獲取非本頁內容，而jsonp的核心則是動態添加<script>標簽來調用服務器提供的js腳本。

$.ajax({  
        url:"http://www.baidu.com/service",  
        dataType:'jsonp',  
        data:'',  
        jsonp:'callback',  
        success:function(data) {  
            // some code
        }  
    });  

　　上面的代碼中，callback是必須的，callback是什么值要跟后台拿。獲取到的jsonp數據格式如下：

callback({
    "code": "CA1998",
    "price": 1780,
    "tickets": 5
});

 ③JSONP的不足之處：

1. 只能使用get方法，不能使用post方法：我們知道 script，link, img 等等標簽引入外部資源，都是 get 請求的，那么就決定了 jsonp 一定是 get 的。但有時候我們使用的 post 請求也成功，為啥呢？這是因為當我們指定dataType:'jsonp',不論你指定：type:"post" 或者type:"get"，其實質上進行的都是 get 請求！
2. 沒有關於 JSONP 調用的錯誤處理。如果動態腳本插入有效，就執行調用；如果無效，就靜默失敗。失敗是沒有任何提示的。例如，不能從服務器捕捉到 404 錯誤，也不能取消或重新開始請求。不過，等待一段時間還沒有響應的話，就不用理它了。

2、跨域資源共享 CORS

​ 　　Cross-Origin Resource Sharing（CORS）跨域資源共享是一份瀏覽器技術的規范，提供了 Web 服務從不同域傳來沙盒腳本的方法，以避開瀏覽器的同源策略，確保安全的跨域數據傳輸。現代瀏覽器使用CORS在API容器如XMLHttpRequest來減少HTTP請求的風險來源。與 JSONP 不同，CORS 除了 GET 要求方法以外也支持其他的 HTTP 要求。

　　瀏覽器將CORS請求分成兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。由於該類跨域方案使用較為廣泛，本篇將詳細介紹。

2.1簡單請求

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

（1）請求方法是以下三種方法之一：

HEAD 2 GET 3 POST

（2）HTTP的頭信息不超出以下幾種字段：

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

2.1.1基本流程

　　對於簡單請求，瀏覽器直接發出CORS請求。具體來說，就是在頭信息之中，增加一個Origin字段。下面是一個例子，瀏覽器發現這次跨源AJAX請求是簡單請求，就自動在頭信息之中，添加一個Origin字段。

GET /cors HTTP/1.1 2 Origin: http://api.bob.com 3 Host: api.alice.com 4 Accept-Language: en-US 5 Connection: keep-alive 6 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 2 Access-Control-Allow-Credentials: true 3 Access-Control-Expose-Headers: FooBar 4 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字段的值。

2.1.2 withCredentials 屬性

　　上面說到，CORS請求默認不發送Cookie和HTTP認證信息。如果要把Cookie發到服務器，一方面要服務器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials: true

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

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

　　否則，即使服務器同意發送Cookie，瀏覽器也不會發送。或者，服務器要求設置Cookie，瀏覽器也不會處理。但是，如果省略withCredentials設置，有的瀏覽器還是會一起發送Cookie。這時，可以顯式關閉withCredentials。

xhr.withCredentials = false;

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

2.2非簡單請求

2.2.1 預檢請求

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

　　非簡單請求的CORS請求，會在正式通信之前，增加一次HTTP查詢請求，稱為"預檢"請求（preflight）。瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復，瀏覽器才會發出正式的XMLHttpRequest請求，否則就報錯。

　　下面是一段瀏覽器的JavaScript腳本。

var url = 'http://api.alice.com/cors'; 2 var xhr = new XMLHttpRequest(); 3 xhr.open('PUT', url, true); 4 xhr.setRequestHeader('X-Custom-Header', 'value'); 5 xhr.send();

　　上面代碼中，HTTP請求的方法是PUT，並且發送一個自定義頭信息X-Custom-Header。瀏覽器發現，這是一個非簡單請求，就自動發出一個"預檢"請求，要求服務器確認可以這樣請求。下面是這個"預檢"請求的HTTP頭信息。

OPTIONS /cors HTTP/1.1 2 Origin: http://api.bob.com 3 Access-Control-Request-Method: PUT 4 Access-Control-Request-Headers: X-Custom-Header 5 Host: api.alice.com 6 Accept-Language: en-US 7 Connection: keep-alive 8 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。

2.2.2 預檢請求的回應

　　服務器收到"預檢"請求以后，檢查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，確認允許跨源請求，就可以做出回應。

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

　　上面的HTTP回應中，關鍵的是Access-Control-Allow-Origin字段，表示http://api.bob.com可以請求數據。該字段也可以設為星號，表示同意任意跨源請求。

Access-Control-Allow-Origin: *

　　如果瀏覽器否定了"預檢"請求，會返回一個正常的HTTP回應，但是沒有任何CORS相關的頭信息字段。這時，瀏覽器就會認定，服務器不同意預檢請求，因此觸發一個錯誤，被XMLHttpRequest對象的onerror回調函數捕獲。控制台會打印出如下的報錯信息。

XMLHttpRequest cannot load http://api.alice.com. 2 Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

　　服務器回應的其他CORS相關字段如下。

Access-Control-Allow-Methods: GET, POST, PUT 2 Access-Control-Allow-Headers: X-Custom-Header 3 Access-Control-Allow-Credentials: true 4 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天），在此期間，不用發出另一條預檢請求。

2.2.3 瀏覽器的正常請求和回應

　　一旦服務器通過了"預檢"請求，以后每次瀏覽器正常的CORS請求，就都跟簡單請求一樣，會有一個Origin頭信息字段。服務器的回應，也都會有一個Access-Control-Allow-Origin頭信息字段。下面是"預檢"請求之后，瀏覽器的正常CORS請求。

PUT /cors HTTP/1.1 2 Origin: http://api.bob.com 3 Host: api.alice.com 4 X-Custom-Header: value 5 Accept-Language: en-US 6 Connection: keep-alive 7 User-Agent: Mozilla/5.0...

　　上面頭信息的Origin字段是瀏覽器自動添加的。下面是服務器正常的回應。

Access-Control-Allow-Origin: http://api.bob.com 2 Content-Type: text/html; charset=utf-8

　　上面頭信息中，Access-Control-Allow-Origin字段是每次回應都必定包含的。

　　CORS實現起來比較簡單，但是缺點是支持瀏覽器有限。

     

3、反向代理

　　想一下，如果我們請求的時候還是用前端的域名，然后有個東西幫我們把這個請求轉發到真正的后端域名上，不就避免跨域了嗎？這時候，Nginx出場了。
Nginx配置

server{  2  # 監聽9099端口  3     listen 9099;  4  # 域名是localhost  5  server_name localhost;  6     #凡是localhost:9099/api這個樣子的，都轉發到真正的服務端地址http://localhost:9871 
    location ^~ /api {  8         proxy_pass http://localhost:9871;
 } 10 }

　　前端就不用干什么事情了，除了寫接口，也沒后端什么事情了

// 請求的時候直接用回前端這邊的域名http://localhost:9099，這就不會跨域，然后Nginx監聽到凡是localhost:9099/api這個樣子的，都轉發到真正的服務端地址http://localhost:9871 
fetch('http://localhost:9099/api/iframePost', {  3   method: 'POST',  4  headers: {  5     'Accept': 'application/json',  6     'Content-Type': 'application/json'
 },  8  body: JSON.stringify({  9     msg: 'helloIframePost'
 }) 11 })

　　Nginx轉發的方式似乎很方便！但這種使用也是看場景的，如果后端接口是一個公共的API，比如一些公共服務獲取天氣什么的，前端調用的時候總不能讓運維去配置一下Nginx，如果兼容性沒問題（IE 10或者以上），CROS才是更通用的做法吧。