跨域 · 前端筆記

[TOC] ## 概述 <br> ### 什么是同源 > 只要協議、域名、端口有任何一個不同，都被當作是不同的域。 > | URL | 說明 | 是否允許通信 | | --- | --- | --- | | http://www.a.com/a.js <br>http://www.a.com/b.js | 同一域名下 | 允許 | | http://www.a.com/lab/a.js <br >http://www.a.com/script/b.js | 同一域名下不同文件夾 | 允許 | | http://www.a.com:8000/a.js <br > http://www.a.com/b.js | 同一域名，不同端口 | 不允許 | | http://www.a.com/a.js <br> https://www.a.com/b.js | 同一域名，不同協議 | 不允許 | | http://www.a.com/a.js <br> http://70.32.92.74/b.js | 域名和域名對應ip | 不允許 | | http://www.a.com/a.js <br> http://script.a.com/b.js | 主域相同，子域不同 | 不允許 | | http://www.a.com/a.js <br> http://a.com/b.js | 同一域名，不同二級域名（同上） | 不允許（cookie這種情況下也不允許訪問） | | http://www.cnblogs.com/a.js <br> http://www.a.com/b.js | 不同域名 | 不允許 | <br> ### 限制范圍目前，如果非同源，共有三種行為受到限制： 1. Cookie、LocalStorage 和 IndexDB 無法讀取。 2. DOM 無法獲得。 3. AJAX 請求不能發送。 <br> ### 其他 1. 如果是協議和端口造成的跨域問題“前臺”是無能為力的； 2. 在跨域問題上，域僅僅是通過“URL的首部”來識別而不會去嘗試判斷相同的ip地址對應著兩個域或兩個域是否在同一個ip上。 (“URL的首部”指 window.location.protocol + window.location.host，也可以理解為“Domains, protocols and ports must match”。) <br> <br> ## 主域相同子域不同 <br> ### document.domain 這種方法只適用于 Cookie 和 iframe 窗口，LocalStorage 和 IndexDB 無法通過這種方法。我們只能把document.domain設置成自身或更高一級的父域，且主域必須相同。 #### iframe 在頁面http://www.damonare.cn/a.html 中設置document.domain: ~~~ <iframe id = "iframe" src="http://damonare.cn/b.html" onload = "test()"></iframe> <script type="text/javascript"> document.domain = 'damonare.cn';//設置成主域 function test(){ alert(document.getElementById('?iframe').contentWindow);//contentWindow 可取得子窗口的 window 對象 } </script> ~~~ 在頁面http://damonare.cn/b.html 中也設置document.domain: ~~~ <script type="text/javascript"> document.domain = 'damonare.cn'; //在iframe載入這個頁面也設置document.domain，使之與主頁面的document.domain相同 </script> ~~~ <br> #### Cookie Cookie 是服務器寫入瀏覽器的一小段信息，只有同源的網頁才能共享。但是，兩個網頁一級域名相同，只是二級域名不同，瀏覽器允許通過設置document.domain共享 Cookie。假設A網頁為 http://w1.example.com/a.html ，B網頁為 http://w2.example.com/b.html ，那么只要設置相同的document.domain，兩個網頁就可以共享Cookie。 ~~~ //A頁面 <script> document.domain = 'example.com'; //設置domain document.cookie = "test1=hello"; //設置cookie </script> //B頁面 <script> document.domain = 'example.com'; //設置domain var allCookie = document.cookie; //讀取cookie </script> ~~~ <br> ## 完全不同源 <br> ### iframe location.hash 因為父窗口可以對iframe進行URL讀寫，iframe也可以讀寫父窗口的URL，URL有一部分被稱為hash，就是#號及其后面的字符，它一般用于瀏覽器錨點定位，Server端并不關心這部分，應該說HTTP請求過程中不會攜帶hash，所以這部分的修改不會產生HTTP請求，但是會產生瀏覽器歷史記錄。此方法的原理就是改變URL的hash部分來進行雙向通信。每個window通過改變其他 window的location來發送消息（由于兩個頁面不在同一個域下IE、Chrome不允許修改parent.location.hash的值，所以要借助于父窗口域名下的一個代理iframe），并通過監聽自己的URL的變化來接收消息。這個方式的通信會造成一些不必要的瀏覽器歷史記錄，而且有些瀏覽器不支持onhashchange事件，需要輪詢來獲知URL的改變，最后，這樣做也存在缺點，諸如數據直接暴露在了url中，數據容量和類型都有限等。 1. cs1.html首先創建自動創建一個隱藏的iframe，iframe的src指向cnblogs.com域名下的cs2.html頁面 2. cs2.html響應請求后再將通過修改cs1.html的hash值來傳遞數據 3. 同時在cs1.html上加一個定時器，隔一段時間來判斷location.hash的值有沒有變化，一旦有變化則獲取獲取hash值注：由于兩個頁面不在同一個域下IE、Chrome不允許修改parent.location.hash的值，所以要借助于a.com域名下的一個代理iframe a.com下的文件cs1.html文件： ~~~ function startRequest(){ var ifr = document.createElement('iframe'); ifr.style.display = 'none'; ifr.src = 'http://www.cnblogs.com/lab/cscript/cs2.html#paramdo'; document.body.appendChild(ifr); } function checkHash() { try { var data = location.hash ? location.hash.substring(1) : ''; if (console.log) { console.log('Now the data is '+data); } } catch(e) {}; } setInterval(checkHash, 2000); ~~~ cnblogs.com域名下的cs2.html： ~~~ //模擬一個簡單的參數處理操作 switch(location.hash){ case '#paramdo': callBack(); break; case '#paramset': //do something…… break; } function callBack(){ try { parent.location.hash = 'somedata'; } catch (e) { // ie、chrome的安全機制無法修改parent.location.hash， // 所以要利用一個中間的cnblogs域下的代理iframe var ifrproxy = document.createElement('iframe'); ifrproxy.style.display = 'none'; ifrproxy.src = 'http://a.com/test/cscript/cs3.html#somedata'; // 注意該文件在"a.com"域下 document.body.appendChild(ifrproxy); } } ~~~ <br> ### window.name window對象有個name屬性，該屬性有個特征：即在一個窗口(window)的生命周期內,窗口載入的所有的頁面都是共享一個window.name的，每個頁面對window.name都有讀寫的權限，window.name是持久存在一個窗口載入過的所有頁面中的，并不會因新頁面的載入而進行重置。這種方法的優點是，window.name容量很大，可以放置非常長的字符串；缺點是必須監聽子窗口window.name屬性的變化，影響網頁性能。 1. 創建 a.com/cs1.html 2. 創建 a.com/proxy.html，并加入如下代碼： ~~~ <head> <script> function proxy(url, func){ var isFirst = true, ifr = document.createElement('iframe'), loadFunc = function(){ if(isFirst){ ifr.contentWindow.location = 'http://a.com/cs1.html'; isFirst = false; }else{ func(ifr.contentWindow.name); ifr.contentWindow.close(); document.body.removeChild(ifr); ifr.src = ''; ifr = null; } }; ifr.src = url; ifr.style.display = 'none'; if(ifr.attachEvent) ifr.attachEvent('onload', loadFunc); else ifr.onload = loadFunc; document.body.appendChild(iframe); } </script> </head> <body> <script> proxy('http://www.baidu.com/', function(data){ console.log(data); }); </script> </body> ~~~ 3. 在 b.com/cs1.html中包含： ~~~ <script> window.name = '要傳送的內容'; </script> ~~~ <br> ### window.postMessage HTML5引入了一個全新的API：跨文檔通信 API（Cross-document messaging）。高級瀏覽器Internet Explorer 8+, chrome，Firefox , Opera 和 Safari 都將支持這個功能。這個功能主要包括接受信息的 message 事件和發送消息的 postMessage 方法，允許跨窗口通信，不論這兩個窗口是否同源。它可用于解決以下方面的問題： * 頁面和其打開的新窗口的數據傳遞 * 多窗口之間消息傳遞 * 頁面與嵌套的iframe消息傳遞 * 上面三個場景的跨域數據傳遞 > otherWindow.postMessage(message, targetOrigin); * otherWindow:指目標窗口，也就是給哪個window發消息，是 window.frames 屬性的成員或者由 window.open 方法創建的窗口 * message: 是要發送的消息，類型為 String、Object (IE8、9 不支持) * targetOrigin: 接收消息的窗口的源（origin），即"協議 + 域名 + 端口"。也可以設為*，表示不限制域名，向所有窗口發送。 ~~~ //窗口http://aaa.com向子窗口http://bbb.com發消息 var popup = window.open('http://bbb.com', 'title'); popup.postMessage('Hello World!', 'http://bbb.com'); //子窗口向父窗口發送消息 window.opener.postMessage('Nice to see you', 'http://aaa.com'); ~~~ message事件的事件對象event，提供以下三個屬性。 * event.source：發送消息的窗口 * event.origin: 消息發向的網址 * event.data: 消息內容 ~~~ if (typeof window.addEventListener != 'undefined') { window.addEventListener('message', onmessage, false); } else if (typeof window.attachEvent != 'undefined') { //for ie window.attachEvent('onmessage', onmessage); } var onmessage = function (event) { console.log(event.data); }; ~~~ 子窗口通過event.source屬性引用父窗口，然后發送消息。 ~~~ window.addEventListener('message', receiveMessage); function receiveMessage(event) { event.source.postMessage('Nice to see you!', '*'); } ~~~ event.origin屬性可以過濾不是發給本窗口的消息。 ~~~ window.addEventListener('message', receiveMessage); function receiveMessage(event) { if (event.origin !== 'http://aaa.com') return; if (event.data === 'Hello World') { event.source.postMessage('Hello', event.origin); } else { console.log(event.data); } } ~~~ <br> ### localStorage 通過window.postMessage，讀寫其他窗口的 LocalStorage 也成為了可能。主窗口寫入iframe子窗口的localStorag。 ~~~ //子窗口將父窗口發來的消息，寫入自己的LocalStorage。 window.onmessage = function(e) { if (e.origin !== 'http://bbb.com') { return; } var payload = JSON.parse(e.data); localStorage.setItem(payload.key, JSON.stringify(payload.data)); }; //父窗口發送消息的代碼 var win = document.getElementsByTagName('iframe')[0].contentWindow; var obj = { name: 'Jack' }; win.postMessage(JSON.stringify({key: 'storage', data: obj}), 'http://bbb.com'); ~~~ 加強版的子窗口接收消息的代碼如下： ~~~ window.onmessage = function(e) { if (e.origin !== 'http://bbb.com') return; var payload = JSON.parse(e.data); switch (payload.method) { case 'set': localStorage.setItem(payload.key, JSON.stringify(payload.data)); break; case 'get': var parent = window.parent; var data = localStorage.getItem(payload.key); parent.postMessage(data, 'http://aaa.com'); break; case 'remove': localStorage.removeItem(payload.key); break; } }; ~~~ 加強版的父窗口發送消息代碼如下： ~~~ var win = document.getElementsByTagName('iframe')[0].contentWindow; var obj = { name: 'Jack' }; // 存入對象 win.postMessage(JSON.stringify({key: 'storage', method: 'set', data: obj}), 'http://bbb.com'); // 讀取對象 win.postMessage(JSON.stringify({key: 'storage', method: "get"}), "*"); window.onmessage = function(e) { if (e.origin != 'http://aaa.com') return; // "Jack" console.log(JSON.parse(e.data).name); }; ~~~ ### JSONP JSONP是服務器與客戶端跨源通信的常用方法。最大特點就是簡單適用，老式瀏覽器全部支持，服務器改造非常小。原理：當我們通過script標簽請求時，后臺就會根據相應的參數(json,handleResponse)來生成相應的json數據。最后這個返回的json數據(代碼)就會被放在當前js文件中被執行，至此跨域通信完成缺點： * 它只支持GET請求而不支持POST等其它類型的HTTP請求 * 它只支持跨域HTTP請求這種情況，不能解決不同域的兩個頁面之間如何進行JavaScript調用的問題。 * 調用失敗的時候不會返回各種HTTP狀態碼。 * 安全性低。 #### JSONP的實現流程 * 聲明一個回調函數，其函數名(如show)當做參數值，要傳遞給跨域請求數據的服務器，函數形參為要獲取目標數據(服務器返回的data)。 * 創建一個`<script>`標簽，把那個跨域的API數據接口地址，賦值給script的src,還要在這個地址中向服務器傳遞該函數名（可以通過問號傳參:?callback=show）。 * 服務器接收到請求后，需要進行特殊的處理：把傳遞進來的函數名和它需要給你的數據拼接成一個字符串,例如：傳遞進去的函數名是show，它準備好的數據是`show('我不愛你')`。 * 最后服務器把準備的數據通過HTTP協議返回給客戶端，客戶端再調用執行之前聲明的回調函數（show），對返回的數據進行操作。在開發中可能會遇到多個 JSONP 請求的回調函數名是相同的，這時候就需要自己封裝一個 JSONP函數。 ~~~ function jsonp({ url, params, callback }) { return new Promise((resolve, reject) => { // 創建 script標簽 let script = document.createElement('script') // 聲明一個回調函數，其函數名(如show)當做參數值，要傳遞給跨域請求數據的服務器 // 函數形參 data 為要獲取目標數據(接口返回的數據) window[callback] = function(data) { // 執行jsonp返回的函數 resolve(data) // 移除添加的script document.body.removeChild(script) } // params 和 callback 參數轉換成 ?wd=Iloveyou&callback=show 形式 params = { ...params, callback } let arrs = [] for (let key in params) { arrs.push(`${key}=${params[key]}`) } script.src = `${url}?${arrs.join('&')}` // 添加scirpt標簽 document.body.appendChild(script) }) } jsonp({ url: 'http://localhost:3000/say', params: { wd: 'Iloveyou' }, callback: 'show' }).then(data => { console.log(data) }) ~~~ <br> 上面這段代碼相當于向`http://localhost:3000/say?wd=Iloveyou&callback=show`這個地址請求數據，然后后臺返回`show('我不愛你')`，最后會運行show()這個函數，打印出'我不愛你' ~~~ // server.js let express = require('express') let app = express() app.get('/say', function(req, res) { let { wd, callback } = req.query console.log(wd) // Iloveyou console.log(callback) // show res.end(`${callback}('我不愛你')`) }) app.listen(3000) ~~~ 從JQery 1.2以后，就開始支持JSONP的調用。在另外的一個域名中指定好回調函數名稱，你就可以用下面的形式來就加載JSON數據。 ~~~ $.getJSON(url + "&callbak=?", function(data) { alert("Symbol:" + data.symbol + ", Price:" + data.price); }); ~~~ jQuery會在window對象中加載一個全局的函數，當代碼插入時函數執行，執行完畢后就會被移除。同時jquery還對非跨域的請求進行了優化，如果這個請求是在同一個域名下那么他就會像正常的Ajax請求一樣工作。上例中我們在動態插入到頁面的代碼中使用了靜態的json數據，雖然完成了依次JSONP返回，但仍不是JSONP服務，因為不支持在URL中定義回調函數名稱。下面是一個將其變成JSONP服務的一個方法。首先我們來定義接口的規范，http://www.mydomain.com/jsonp/ticker?symbol=IBM&callback=showPrice 。symbol是請求條件，callback是回調函數名稱。 ~~~ //JQuery JSONP Support var url = "http://www.mydomain.com/api/suggest.php?symbol=IBM&callback=?"; $.getJSON(url, function(data){ alert("Symbol:" + data.symbol + ", Price:" + data.price); }); ~~~ 在suggest.php中： ~~~ $jsondata = "{symbol:'IBM', price:120}"; echo $_GET['callback'].'('.$jsondata.')'; ~~~ <br> ### WebSocket WebSocket是一種通信協議，使用ws://（非加密）和 wss://（加密）作為協議前綴。該協議不實行同源政策，只要服務器支持，就可以通過它進行跨源通信。只有在支持web socket協議的服務器上才能正常工作。 ~~~ var iframe = document.getElementById('iframe'); var data = ''; iframe.onload = function() { iframe.onload = function(){ data = iframe.contentWindow.name; } iframe.src = 'about:blank'; }; ~~~ 瀏覽器發出的WebSocket請求的頭信息 ~~~ GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com ~~~ 上面代碼中，有一個字段是Origin，表示該請求的請求源（origin），即發自哪個域名。正是因為有了Origin這個字段，所以WebSocket才沒有實行同源政策。因為服務器可以根據這個字段，判斷是否許可本次通信。如果該域名在白名單內，服務器就會做出如下回應。 ~~~ HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat ~~~ ### CORS CORS是跨源資源分享（Cross-Origin Resource Sharing）的縮寫。它是W3C標準，是跨源AJAX請求的根本解決方法。相比JSONP只能發GET請求，CORS允許任何類型的請求。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低于IE10。整個CORS通信過程，都是瀏覽器自動完成，不需要用戶參與。對于開發者來說，CORS通信與同源的AJAX通信沒有差別，代碼完全一樣。瀏覽器一旦發現AJAX請求跨源，就會自動添加一些附加的頭信息，有時還會多出一次附加的請求，但用戶不會有感覺。實現CORS通信的關鍵是服務器。只要服務器實現了CORS接口，就可以跨源通信。瀏覽器將CORS請求分成兩類：簡單請求（simple request）和非簡單請求（not-so-simple request）。只要同時滿足以下兩大條件，就屬于簡單請求。請求方法是以下三種方法之一： * HEAD * GET * POST HTTP的頭信息不超出以下幾種字段 * Accept * Accept-Language * Content-Language * Last-Event-ID * Content-Type：只限于三個值application/x-www-form-urlencoded、multipart/form-data、text/plain 凡是不同時滿足上面兩個條件，就屬于非簡單請求。 #### 簡單請求 **基本流程** 對于簡單請求，瀏覽器直接發出CORS請求。具體來說，就是在頭信息之中，增加一個Origin字段。下面是一個例子，瀏覽器發現這次跨源AJAX請求是簡單請求，就自動在頭信息之中，添加一個Origin字段。 ~~~ GET /cors HTTP/1.1 Origin: http://api.bob.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-開頭。 * Access-Control-Allow-Origin：該字段是必須的。它的值要么是請求時Origin字段的值，要么是一個*，表示接受任意域名的請求。 * Access-Control-Allow-Credentials：該字段可選。它的值是一個布爾值，表示是否允許發送Cookie。默認情況下，Cookie不包括在CORS請求之中。設為true，即表示服務器明確許可，Cookie可以包含在請求中，一起發給服務器。這個值也只能設為true，如果服務器不要瀏覽器發送Cookie，刪除該字段即可。 * 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。 > <br> #### 非簡單請求 **預檢請求** 非簡單請求是那種對服務器有特殊要求的請求，比如請求方法是PUT或DELETE，或者Content-Type字段的類型是application/json。非簡單請求的CORS請求，會在正式通信之前，增加一次HTTP查詢請求，稱為"預檢"請求（preflight）。瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答復，瀏覽器才會發出正式的XMLHttpRequest請求，否則就報錯。下面是一段瀏覽器的JavaScript腳本。 ~~~ var url = 'http://api.alice.com/cors'; 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://api.bob.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字段，"預檢"請求的頭信息包括兩個特殊字段。 * Access-Control-Request-Method：該字段是必須的，用來列出瀏覽器的CORS請求會用到哪些HTTP方法，上例是PUT。 * Access-Control-Request-Headers：該字段是一個逗號分隔的字符串，指定瀏覽器CORS請求會額外發送的頭信息字段，上例是X-Custom-Header。 **預檢請求的回應** 服務器收到"預檢"請求以后，檢查了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://api.bob.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://api.bob.com 可以請求數據。該字段也可以設為星號，表示同意任意跨源請求。 ~~~ Access-Control-Allow-Origin: * ~~~ 如果瀏覽器否定了"預檢"請求，會返回一個正常的HTTP回應，但是沒有任何CORS相關的頭信息字段。這時，瀏覽器就會認定，服務器不同意預檢請求，因此觸發一個錯誤，被XMLHttpRequest對象的onerror回調函數捕獲。控制臺會打印出如下的報錯信息。 ~~~ XMLHttpRequest cannot load http://api.alice.com. Origin http://api.bob.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 ~~~ * Access-Control-Allow-Methods：該字段必需，它的值是逗號分隔的一個字符串，表明服務器支持的所有跨域請求的方法。注意，返回的是所有支持的方法，而不單是瀏覽器請求的那個方法。這是為了避免多次"預檢"請求。 * Access-Control-Allow-Headers：如果瀏覽器請求包括Access-Control-Request-Headers字段，則Access-Control-Allow-Headers字段是必需的。它也是一個逗號分隔的字符串，表明服務器支持的所有頭信息字段，不限于瀏覽器在"預檢"中請求的字段。 * Access-Control-Allow-Credentials：該字段與簡單請求時的含義相同。 * Access-Control-Max-Age：該字段可選，用來指定本次預檢請求的有效期，單位為秒。上面結果中，有效期是20天（1728000秒），即允許緩存該條回應1728000秒（即20天），在此期間，不用發出另一條預檢請求。 <br> **瀏覽器的正常請求和回應** 一旦服務器通過了"預檢"請求，以后每次瀏覽器正常的CORS請求，就都跟簡單請求一樣，會有一個Origin頭信息字段。服務器的回應，也都會有一個Access-Control-Allow-Origin頭信息字段。下面是"預檢"請求之后，瀏覽器的正常CORS請求。 ~~~ PUT /cors HTTP/1.1 Origin: http://api.bob.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://api.bob.com Content-Type: text/html; charset=utf-8 ~~~ 上面頭信息中，Access-Control-Allow-Origin字段是每次回應都必定包含的。 ### nginx 實現原理類似于Node中間件代理，需要你搭建一個中轉nginx服務器，用于轉發請求。 <br> 使用nginx反向代理實現跨域，是最簡單的跨域方式。只需要修改nginx的配置即可解決跨域問題，支持所有瀏覽器，支持session，不需要修改任何代碼，并且不會影響服務器性能。 <br> 實現思路：通過nginx配置一個代理服務器（域名與domain1相同，端口不同）做跳板機，反向代理訪問domain2接口，并且可以順便修改cookie中domain信息，方便當前域cookie寫入，實現跨域登錄。 <br> 先下載[nginx](http://nginx.org/en/download.html)，然后將nginx目錄下的nginx.conf修改如下: ~~~ // proxy服務器 server { listen 80; server_name www.domain1.com; location / { proxy_pass http://www.domain2.com:8080; #反向代理 proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里域名 index index.html index.htm; # 當用webpack-dev-server等中間件代理接口訪問nignx時，此時無瀏覽器參與，故沒有同源限制，下面的跨域配置可不啟用 add_header Access-Control-Allow-Origin http://www.domain1.com; #當前端只跨域不帶cookie時，可為* add_header Access-Control-Allow-Credentials true; } } ~~~ 最后通過命令行`nginx -s reload`啟動nginx ~~~ // index.html var xhr = new XMLHttpRequest(); // 前端開關：瀏覽器是否讀寫cookie xhr.withCredentials = true; // 訪問nginx中的代理服務器 xhr.open('get', 'http://www.domain1.com:81/?user=admin', true); xhr.send(); ~~~ ~~~ // server.js var http = require('http'); var server = http.createServer(); var qs = require('querystring'); server.on('request', function(req, res) { var params = qs.parse(req.url.substring(2)); // 向前臺寫cookie res.writeHead(200, { 'Set-Cookie': 'l=a123456;Path=/;Domain=www.domain2.com;HttpOnly' // HttpOnly:腳本無法讀取 }); res.write(JSON.stringify(params)); res.end(); }); server.listen('8080'); console.log('Server is running at port 8080...'); ~~~ <br> ### 使用 http-proxy-middleware 實現跨域 NodeJS 中間件`http-proxy-middleware`實現跨域代理，原理大致與`nginx`相同，都是通過啟一個代理服務器，實現數據的轉發，也可以通過設置`cookieDomainRewrite`參數修改響應頭中`cookie`中的域名，實現當前域的`cookie`寫入，方便接口登錄認證。 #### 1、非 vue 框架的跨域（2 次跨域） ~~~  <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>proxy 跨域</title> </head> <body> <script> var xhr = new XMLHttpRequest(); // 前端開關：瀏覽器是否讀寫 cookie xhr.withCredentials = true; // 訪問 http-proxy-middleware 代理服務器 xhr.open('get', 'http://www.proxy1.com:3000/login?user=admin', true); xhr.send(); </script> </body> </html> ~~~ 中間代理服務中使用了`http-proxy-middleware`中間件，因此需要提前下載： > npm install http-proxy-middleware --save-dev ~~~ // 中間代理服務器 const express = require("express"); let proxy = require("http-proxy-middleware"); let app = express(); app.use( "/", proxy({ // 代理跨域目標接口 target: "http://www.proxy2.com:8080", changeOrigin: true, // 修改響應頭信息，實現跨域并允許帶 cookie onProxyRes: function(proxyRes, req, res) { res.header("Access-Control-Allow-Origin", "http://www.proxy1.com"); res.header("Access-Control-Allow-Credentials", "true"); }, // 修改響應信息中的 cookie 域名 cookieDomainRewrite: "www.proxy1.com" // 可以為 false，表示不修改 }) ); app.listen(3000); ~~~ ~~~ // 服務器 const http = require("http"); const qs = require("querystring"); const server = http.createServer(); server.on("request", function(req, res) { let params = qs.parse(req.url.substring(2)); // 向前臺寫 cookie res.writeHead(200, { "Set-Cookie": "l=a123456;Path=/;Domain=www.proxy2.com;HttpOnly" // HttpOnly：腳本無法讀取 }); res.write(JSON.stringify(params)); res.end(); }); server.listen("8080"); ~~~ #### 2、vue 框架的跨域（1 次跨域）利用**node + webpack + webpack-dev-server**代理接口跨域。在開發環境下，由于`Vue`渲染服務和接口代理服務都是`webpack-dev-server`，所以頁面與代理接口之間不再跨域，無須設置`Headers`跨域信息了。 ~~~ // 導出服務器配置 module.exports = { entry: {}, module: {}, ... devServer: { historyApiFallback: true, proxy: [{ context: '/login', target: 'http://www.proxy2.com:8080', // 代理跨域目標接口 changeOrigin: true, secure: false, // 當代理某些 https 服務報錯時用 cookieDomainRewrite: 'www.domain1.com' // 可以為 false，表示不修改 }], noInfo: true } } ~~~ # 參考資料 * [九種 “姿勢” 讓你徹底解決跨域問題](https://segmentfault.com/a/1190000016653873) * [九種跨域方式實現原理（完整版）](https://github.com/ljianshu/Blog/issues/55)