為確保內容的實時、準確性, 可以檢視原文
跨域是日常開發中經常開發中經常會接觸到的一個重難點知識,何不總結實踐一番,從此心中對之了無牽掛。
同源策略
之所以會出現跨域解決方案,是因為同源策略的限制。同源策略規定了如果兩個 url 的協議、域名、埠中有任何一個不等,就認定它們跨源了。比如下列表格列出和 http://127.0.0.1:3000
比較的同源檢測的結果,
url | 結果 | 原因 |
---|---|---|
http://127.0.0.1:3000/index | 同源 | |
https://127.0.0.1:3000 | 跨源 | 協議不同 |
https://localhost:3000 | 跨源 | 域名不同 |
http://127.0.0.1:3001 | 跨源 | 埠不同 |
那跨源有什麼後果呢?歸納有三:不能獲取 Cookie、LocalStorage、IndexedDB;不能獲取 dom 節點;不能進行一般的 Ajax 通訊;跨域解決方案的出現就是為了解決以上痛處。
JSONP 跨域
提到 JSONP 跨域,不得不先提到 script
標籤,和 img
、iframe
標籤類似,這些標籤是不受同源策略限制的,JSONP 的核心就是通過動態載入 script 標籤來完成對目標 url 的請求。
先來看一段 JSONP 呼叫的 Headers
部分,欄位如下:
Request URL:http://127.0.0.1:3000/?callback=handleResponse
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:3000
複製程式碼
可以很鮮明地發現在 Request URL
中有一句 ?callback=handleResponse
,這個 callback 後面跟著的 handleResponse 即回撥函式名(可以任意取),服務端會接收到這個引數然後拼接成形如 handleResponse(JSON)
的形式返還給前端(這也是 JSONP == JSON with padding 的原因吧),如下圖,這時候瀏覽器就會自動呼叫我們事先定義好的 handleResponse 函式。
前端程式碼示例:(源為 http://127.0.0.1:3001)
function handleResponse(res) {
console.log(res) // {text: "jsonp"}
}
const script = document.createElement('script')
script.src = 'http://127.0.0.1:3000?callback=handleResponse'
document.head.appendChild(script)
複製程式碼
服務端程式碼示例:(源為 http://127.0.0.1:3000)
const server = http.createServer((req, res) => {
if (~req.url.indexOf('?callback')) { // 簡單處理 JSONP 跨域的時候
const obj = {
"text": 'jsonp',
}
const callback = req.url.split('callback=')[1]
const json = JSON.stringify(obj)
const build = callback + `(${json})`
res.end(build) // 這裡返還給前端的是拼接好的 JSON 物件
}
});
複製程式碼
可以看出 JSONP 具有直接訪問響應文字的優點,但是要想確認 JSONP 是否請求失敗並不容易,因為 script 標籤的 onerror 事件還未得到瀏覽器廣泛的支援,此外它僅能支援 GET 方式呼叫。
CORS 跨域
CORS(Cross-Origin Resource Sharing) 可以理解為加強版的 Ajax,也是目前主流的跨域解決方案。它的核心思想即前端與後端進行 Ajax 通訊時,通過自定義 HTTP 頭部設定從而決定請求或響應是否生效
。
比如前端程式碼(url 為 http://127.0.0.1:3001)寫了段 Ajax,程式碼如下:
const xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
if (xhr.status >= 200 && xhr.status < 300 || xhr.status === 304) {
console.log('responseTesx:' + xhr.responseText)
}
}
}
xhr.open('get', 'http://127.0.0.1:3000', true)
xhr.send()
複製程式碼
因為埠不一致的關係這時候導致不同源了,這時候會在 Request Headers 中發現多了這麼一行欄位,
Origin: http://127.0.0.1:3001
複製程式碼
而且控制檯中會報出如下錯誤:
Failed to load http://127.0.0.1:3000/: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:3001' is therefore not allowed access.
複製程式碼
這時候就需要在服務端設定欄位 Access-Control-Allow-Origin
,它的作用就是設定允許來自什麼源的請求,如果值設定為 *
,表明允許來自任意源的請求。服務端程式碼示例如下:
http.createServer((req, res) => {
res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001') // 設定允許來自 http://127.0.0.1:3001 源的請求
})
複製程式碼
CORS 分為簡單請求以及非簡單請求。可以這麼區分,如果請求方法為 POST
、GET
、HEAD
時為簡單請求,其它方法如 PUT
、DELETE
等為非簡單請求,如果是非簡單請求的話,可以在 chrome 的 Network 中看到多了一次 Request Method
為 OPTIONS
的請求。如下圖:
可以把這個請求稱為預請求,用白話文翻譯下,瀏覽器詢問伺服器,'伺服器大哥,我這次要進行 PUT 請求,你給我發張通行證唄',伺服器大哥見瀏覽器小弟這麼殷勤,於是給了它發了張通行證,叫作 Access-Control-Allow-Methods:PUT
,接著瀏覽器就能愉快地進行 PUT 請求了。服務端程式碼示例如下:
http.createServer((req, res) => {
res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001')
res.setHeader('Access-Control-Allow-Methods', 'http://127.0.0.1:3001')
})
複製程式碼
聊完簡單請求和非簡單請求的區別後,再來看看如何利用 CORS 實現 Cookie 的跨域傳送,首先在伺服器隨意設定個 Cookie 值下發到瀏覽器,如果非跨域的情況下,瀏覽器再次請求伺服器時就會帶上伺服器給的 Cookie,但是跨域的時候怎麼辦呢?不賣關子了,需在服務端設定 Access-Control-Allow-Credentials
欄位以及在客戶端設定 withCredentials
欄位,兩者缺一不可,程式碼如下:
前端程式碼示例:(源為 http://127.0.0.1:3001)
const xhr = new XMLHttpRequest()
...
xhr.withCredentials = true // 傳 cookie 的時候前端要做的
xhr.open('get', 'http://127.0.0.1:3000', true)
xhr.send()
複製程式碼
服務端程式碼示例: (源為 http://127.0.0.1:3000)
const server = http.createServer((req, res) => {
res.setHeader('Access-Control-Allow-Origin', 'http://127.0.0.1:3001') // 必填:接受域的請求
res.setHeader('Set-Cookie', ['type=muyy']) // 下發 cookie
res.setHeader('Access-Control-Allow-Credentials', true) // ② 選填:是否允許瀏覽器傳 cookie 到服務端,只能設定為 true
res.end('date from cors')
})
複製程式碼
至此介紹了幾個比較關鍵 HTTP 頭在 CORS 中的實踐運用,更為詳細的資料可以參閱 Cross-Origin Resource Sharing,最後概括下 CORS 的優缺點,優點是支援所有型別的 HTTP 方法,缺點是有些老的瀏覽器不支援 CORS。
hash + iframe
在文章最開始提到過 iframe 標籤也是不受同源策略限制的標籤之一,hash + iframe 的跨域核心思想就是,在 A 源中通過動態改變 iframe 標籤的 src 的雜湊值,在 B 源中通過 window.onhashchange
來捕獲到相應的雜湊值。思路不難直接上程式碼:
A 頁面程式碼示例(源為 http://127.0.0.1:3000)
<body>
<iframe src="http://127.0.0.1:3001"></iframe>
<script>
const iframe = document.getElementsByTagName('iframe')[0]
iframe.setAttribute('style', 'display: none')
const obj = {
data: 'hash'
}
iframe.src = iframe.src + '#' + JSON.stringify(obj) // ① 關鍵語句
</script>
</body>
複製程式碼
B 頁面程式碼示例(源為 http://127.0.0.1:3001)
window.onhashchange = function() { // ① 關鍵語句
console.log('來自 page2 的程式碼 ' + window.location.hash) // 來自 page2 的程式碼 #{"data":"hash"}
}
複製程式碼
重新整理 A 頁面,可以發現在控制檯列印瞭如下欄位,至此實現了跨域。
來自 page2 的程式碼 #{"data":"hash"}
複製程式碼
這種方式進行跨域優點是支援頁面和頁面間的通訊,缺點也是隻支援 GET 方法和單向的跨域通訊。
postMessage
為了實現跨文件傳送(cross-document messaging),簡稱 XDM。HTML5 給出了一個 api —— postMessage,postMessage() 方法接收兩個引數:傳送訊息
以及訊息接收方所在域的字串
。程式碼示例如下:
A 頁面程式碼示例(源為 http://127.0.0.1:3000)
<body>
<iframe src="http://127.0.0.1:3001"></iframe>
<script>
const iframe = document.getElementsByTagName('iframe')[0]
iframe.setAttribute('style', 'display: none')
iframe.onload = function() { // 此處要等 iframe 載入完畢,後續程式碼才會生效
iframe.contentWindow.postMessage('a secret', 'http://127.0.0.1:3001')
}
</script>
</body>
複製程式碼
B 頁面程式碼示例(源為 http://127.0.0.1:3001)
window.addEventListener('message', function(event) {
console.log('From page1 ' + event.data)
console.log('From page1 ' + event.origin)
}, false)
複製程式碼
重新整理 A 頁面,可以發現在控制檯列印瞭如下欄位,至此實現了跨域。
From page1 a secret
From page1 http://127.0.0.1:3000
複製程式碼
這種跨域方式優點是是支援頁面和頁面間的雙向通訊,缺點也是隻能支援 GET 方法呼叫。
WebSockets
WebSockets 屬於 HTML5 的協議,它的目的是在一個持久連線上建立全雙工通訊。由於 WebSockets 採用了自定義協議,所以優點是客戶端和服務端傳送資料量少,缺點是要額外的伺服器。基礎的使用方法如下:
const ws = new WebSocket('ws://127.0.0.1:3000')
ws.onopen = function() {
// 連線成功建立
}
ws.onmessage = function(event) {
// 處理資料
}
ws.onerror = function() {
// 發生錯誤時觸發,連線中斷
}
ws.onclose = function() {
// 連線關閉時觸發
}
複製程式碼
當然一般我們會使用封裝好 WebSockets 的第三方庫 socket.io,這裡具體就不展開了。
專案地址
前文所述五種跨域實踐的 demo 已上傳至 cross-domain,前端環境基於 create-react-app 搭建,後端環境用 node 搭建。
當然跨域方式還有一些其他方式的實現,後續酌情慢慢填坑~