前端跨域的整理
跨域資源共享 CORS
對於web開發來講,由於瀏覽器的同源策略,我們需要經常使用一些hack的方法去跨域獲取資源,但是hack的方法總歸是hack。直到W3C出了一個標準-CORS-”跨域資源共享”(Cross-origin resource sharing)。
它允許瀏覽器向跨源伺服器,發出XMLHttpRequest請求,從而克服了AJAX只能同源使用的限制。
首先來說 CORS 需要瀏覽器和服務端同時支援的,對於相容性來說主要是ie10+,其它現代瀏覽器都是支援的。
http://caniuse.com/#feat=cors
使用 CORS 跨域的時候其實和普通的 ajax 過程是一樣的,只是瀏覽器在發現這是一個跨域請求的時候會自動幫我們處理一些事,比如驗證等等,所以說只要服務端提供支援,前端是不需要做額外的事情的。
兩種請求
CORS 的請求分兩種,這也是瀏覽器為了安全做的一些處理,不同情況下瀏覽器執行的操作也是不一樣的,主要分為兩種請求,當然這一切我們是不需要做額外處理的,瀏覽器會自動處理的。
簡單請求(simple request)
只要同時滿足以下兩大條件,就屬於簡單請求。
條件
1) 請求方法是以下三種方法中的一個: HEAD GET POST 2)HTTP的頭資訊不超出以下幾種欄位: Accept Accept-Language Content-Language Last-Event-ID Content-Type:只限於三個值application/x-www-form-urlencoded、multipart/form-data、text/plain
過程
對於簡單的跨域請求,瀏覽器會自動在請求的頭資訊加上 Origin 欄位,表示本次請求來自哪個源(協議 + 域名 + 埠),服務端會獲取到這個值,然後判斷是否同意這次請求並返回。
// 請求 GET /cors HTTP/1.1 Origin: http://api.qiutc.me Host: api.alice.com Accept-Language: en-US Connection: keep-alive User-Agent: Mozilla/5.0...
1.服務端允許
如果服務端許可本次請求,就會在返回的頭資訊多出幾個欄位:
// 返回 Access-Control-Allow-Origin: http://api.qiutc.me Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: Info Content-Type: text/html; charset=utf-8
這三個帶有 Access-Control 開頭的欄位分別表示:
-
Access-Control-Allow-Origin
必須。它的值是請求時Origin欄位的值或者 *,表示接受任意域名的請求。 -
Access-Control-Allow-Credentials;
可選。它的值是一個布林值,表示是否允許傳送Cookie。預設情況下,Cookie不包括在CORS請求之中。設為true,即表示伺服器明確許可,Cookie可以包含在請求中,一起發給伺服器。
再需要傳送cookie的時候還需要注意要在AJAX請求中開啟withCredentials屬性:var xhr = new XMLHttpRequest(); xhr.withCredentials = true;
需要注意的是,如果要傳送Cookie,Access-Control-Allow-Origin就不能設為*,必須指定明確的、與請求網頁一致的域名。同時,Cookie依然遵循同源政策,只有用伺服器域名設定的Cookie才會上傳,其他域名的Cookie並不會上傳,且原網頁程式碼中的document.cookie也無法讀取伺服器域名下的Cookie。 -
Access-Control-Expose-Headers
可選。CORS請求時,XMLHttpRequest物件的getResponseHeader()方法只能拿到6個基本欄位:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他欄位,就必須在Access-Control-Expose-Headers裡面指定。上面的例子指定,getResponseHeader('Info')可以返回Info欄位的值。
2.服務端拒絕
當然我們為了防止介面被亂呼叫,需要限制源,對於不允許的源,服務端還是會返回一個正常的HTTP迴應,但是不會帶上 Access-Control-Allow-Origin 欄位,瀏覽器發現這個跨域請求的返回頭資訊沒有該欄位,就會丟擲一個錯誤,會被 XMLHttpRequest 的 onerror 回撥捕獲到。
這種錯誤無法通過 HTTP 狀態碼判斷,因為迴應的狀態碼有可能是200
非簡單請求
條件
出了簡單請求以外的CORS請求。
非簡單請求是那種對伺服器有特殊要求的請求,比如請求方法是PUT或DELETE,或者Content-Type欄位的型別是application/json。
過程
1)預檢請求
非簡單請求的CORS請求,會在正式通訊之前,增加一次HTTP查詢請求,稱為”預檢”請求(preflight)。
瀏覽器先詢問伺服器,當前網頁所在的域名是否在伺服器的許可名單之中,以及可以使用哪些HTTP動詞和頭資訊欄位。只有得到肯定答覆,瀏覽器才會發出正式的XMLHttpRequest請求,否則就報錯。
預檢請求的傳送請求:
OPTIONS /cors HTTP/1.1 Origin: http://api.qiutc.me Access-Control-Request-Method: PUT Access-Control-Request-Headers: X-Custom-Header Host: api.qiutc.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。
預檢請求的返回: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.qiutc.me 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
-
Access-Control-Allow-Methods
必需,它的值是逗號分隔的一個字串,表明伺服器支援的所有跨域請求的方法。注意,返回的是所有支援的方法,而不單是瀏覽器請求的那個方法。這是為了避免多次”預檢”請求。 -
Access-Control-Allow-Headers
如果瀏覽器請求包括Access-Control-Request-Headers欄位,則Access-Control-Allow-Headers欄位是必需的。它也是一個逗號分隔的字串,表明伺服器支援的所有頭資訊欄位,不限於瀏覽器在”預檢”中請求的欄位。 -
Access-Control-Max-Age
該欄位可選,用來指定本次預檢請求的有效期,單位為秒。上面結果中,有效期是20天(1728000秒),即允許快取該條迴應1728000秒(即20天),在此期間,不用發出另一條預檢請求。
2)瀏覽器的正常請求和迴應
一旦伺服器通過了”預檢”請求,以後每次瀏覽器正常的CORS請求,就都跟簡單請求一樣,會有一個Origin頭資訊欄位。伺服器的迴應,也都會有一個Access-Control-Allow-Origin頭資訊欄位。
參考:《跨域資源共享 CORS 詳解》http://www.ruanyifeng.com/blog/2016/04/cors.html
阮大神的文章,複製貼上了不少。
jsonp
jsonp = json + padding
其實對於常用性來說,jsonp應該是使用最經常的一種跨域方式了,他不受瀏覽器相容性的限制。但是他也有他的侷限性,只能傳送 GET 請求,需要服務端和前端規定好,寫法醜陋。
它的原理在於瀏覽器請求 script 資源不受同源策略限制,並且請求到 script 資源後立即執行。
主要做法是這樣的:
-
在瀏覽器端:
首先全域性註冊一個callback回撥函式,記住這個函式名字(比如:resolveJson),這個函式接受一個引數,引數是期望的到的服務端返回資料,函式的具體內容是處理這個資料。
然後動態生成一個 script 標籤,src 為:請求資源的地址+獲取函式的欄位名+回撥函式名稱,這裡的獲取函式的欄位名是要和服務端約定好的,是為了讓服務端拿到回撥函式名稱。(如:www.qiute.com?callbackName=resolveJson)。function resolveJosn(result) { console.log(result.name); } var jsonpScript= document.createElement("script"); jsonpScript.type = "text/javascript"; jsonpScript.src = "http://www.qiute.com?callbackName=resolveJson"; document.getElementsByTagName("head")[0].appendChild(jsonpScript);
-
服務端
在接受到瀏覽器端 script 的請求之後,從url的query的callbackName獲取到回撥函式的名字,例子中是resolveJson。
然後動態生成一段javascript片段去給這個函式傳入引數執行這個函式。比如:resolveJson({name: 'qiutc'});
-
執行
服務端返回這個 script 之後,瀏覽器端獲取到 script 資源,然後會立即執行這個 javascript,也就是上面那個片段。這樣就能根據之前寫好的回撥函式處理這些資料了。
在一些第三方庫往往都會封裝jsonp的操作,比如 jQuery 的$.getJSON。
document.domain
一個頁面框架(iframe/frame)之間(父子或同輩),是能夠獲取到彼此的window物件的,但是這個 window 不能拿到方法和屬性(尼瑪這有什麼用,甩臉)。
// 當前頁面域名 http://blog.qiutc.me/a.html <script> function onLoad() { var iframe =document.getElementById('iframe'); var iframeWindow = iframe.contentWindow; // 這裡可以獲取 iframe 裡面 window 物件,但是幾乎沒用 var doc = iframeWindow.document; // 獲取不到 } </script> <iframe src="http://www.qiutc.me/b.html" onload="onLoad()"</iframe>
這個時候,document.domain 就可以派上用場了,我們只要把 http://blog.qiutc.me/a.html 和 http://www.qiutc.me/b.html 這兩個頁面的 document.domain 都設成相同的域名就可以了。
前提條件:這兩個域名必須屬於同一個基礎域名!而且所用的協議,埠都要一致。
但要注意的是,document.domain 的設定是有限制的,我們只能把 document.domain 設定成自身或更高一級的父域,且主域必須相同。例如:a.b.example.com 中某個文件的 document.domain 可以設成a.b.example.com、b.example.com、example.com中的任意一個,但是不可以設成 c.a.b.example.com,因為這是當前域的子域,也不可以設成baidu.com,因為主域已經不相同了。
這樣我們就可以通過js訪問到iframe中的各種屬性和物件了。
// 主頁面:http://blog.qiutc.me/a.html <script> document.domain = 'qiutc.me'; function onLoad() { var iframe =document.getElementById('iframe'); var iframeWindow = iframe.contentWindow; // 這裡可以獲取 iframe 裡面 window 物件並且能得到方法和屬性 var doc = iframeWindow.document; // 獲取到 } </script> <iframe src="http://www.qiutc.me/b.html" onload="onLoad()"</iframe>
// iframe 裡面的頁面 <script> document.domain = 'qiutc.me'; </script>
window.name
window物件有個name屬性,該屬性有個特徵:即在一個視窗(window)的生命週期內,視窗載入的所有的頁面都是共享一個 window.name 的,每個頁面對 window.name 都有讀寫的許可權,window.name 是持久存在一個視窗載入過的所有頁面中的,並不會因新頁面的載入而進行重置。
比如有一個www.qiutc.me/a.html頁面,需要通過a.html頁面裡的js來獲取另一個位於不同域上的頁面www.qiutc.com/data.html裡的資料。
data.html頁面裡的程式碼很簡單,就是給當前的window.name設定一個a.html頁面想要得到的資料值。data.html裡的程式碼:
<script> window.name = '我是被期望得到的資料'; </script>
那麼在 a.html 頁面中,我們怎麼把 data.html 頁面載入進來呢?顯然我們不能直接在 a.html 頁面中通過改變 window.location 來載入data.html頁面(這簡直扯蛋)因為我們想要即使 a.html頁面不跳轉也能得到 data.html 裡的資料。
答案就是在 a.html 頁面中使用一個隱藏的 iframe 來充當一箇中間人角色,由 iframe 去獲取 data.html 的資料,然後 a.html 再去得到 iframe 獲取到的資料。
充當中間人的 iframe 想要獲取到data.html的通過window.name設定的資料,只需要把這個iframe的src設為www.qiutc.com/data.html就行了。然後a.html想要得到iframe所獲取到的資料,也就是想要得到iframe的window.name的值,還必須把這個iframe的src設成跟a.html頁面同一個域才行,不然根據前面講的同源策略,a.html是不能訪問到iframe裡的window.name屬性的。這就是整個跨域過程。
// a.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> <script> function getData() { var iframe =document.getElementById('iframe'); iframe.onload = function() { var data = iframe.contentWindow.name; // 得到 } iframe.src = 'b.html'; // 這裡b和a同源 } </script> </head> <body> <iframe src="http://www.qiutc.com/data.html" style="display:none" onload="getData()"</iframe> </body> </html>
window.postMessage
window.postMessage(message, targetOrigin) 方法是html5新引進的特性,可以使用它來向其它的window物件傳送訊息,無論這個window物件是屬於同源或不同源。相容性:
http://caniuse.com/#search=postMessage
呼叫postMessage方法的window物件是指要接收訊息的那一個window物件,該方法的第一個引數message為要傳送的訊息,型別只能為字串;第二個引數targetOrigin用來限定接收訊息的那個window物件所在的域,如果不想限定域,可以使用萬用字元 * 。
需要接收訊息的window物件,可是通過監聽自身的message事件來獲取傳過來的訊息,訊息內容儲存在該事件物件的data屬性中。
上面所說的向其他window物件傳送訊息,其實就是指一個頁面有幾個框架的那種情況,因為每一個框架都有一個window物件。在討論第種方法的時候,我們說過,不同域的框架間是可以獲取到對方的window物件的,雖然沒什麼用,但是有一個方法是可用的-window.postMessage。下面看一個簡單的示例,有兩個頁面:
// 主頁面 blog.qiutc.com <script> function onLoad() { var iframe =document.getElementById('iframe'); var iframeWindow = iframe.contentWindow; iframeWindow.postMessage("I'm message from main page."); } </script> <iframe src="http://www.qiutc.me/b.html" onload="onLoad()"</iframe>
// b 頁面 <script> window.onmessage = function(e) { e = e || event; console.log(e.data); } </script>
CSST (CSS Text Transformation)
一種用 CSS 跨域傳輸文字的方案。
優點:相比 JSONP 更為安全,不需要執行跨站指令碼。
缺點:沒有 JSONP 適配廣,CSST 依賴支援 CSS3 的瀏覽器。
原理:通過讀取 CSS3 content 屬性獲取傳送內容。
具體可以參考:CSST (CSS Text Transformation)
利用flash
flash 嘛,這個東西註定滅亡,不想說了。。。
相關文章
- 前端跨域整理前端跨域
- 前端跨域前端跨域
- JS跨域知識整理JS跨域
- 前端跨域方法論前端跨域
- 前端跨域問題前端跨域
- 前端跨域詳解前端跨域
- 前端跨域,不再求人前端跨域
- 前端跨域的解決方案前端跨域
- 那些年前端跨過的域前端
- 常用的-前端跨域的解決前端跨域
- Nginx解決前端跨域問題 CORS跨域配置Nginx前端跨域CORS
- 前端筆記之跨域前端筆記跨域
- 前端跨域方法總結前端跨域
- 實戰前端跨域問題前端跨域
- 前端跨域問題總結前端跨域
- 前端跨域方法之proxy(代理)前端跨域
- 前端跨域常用方法小結前端跨域
- 前端跨域知識總結前端跨域
- 由同源策略到前端跨域前端跨域
- 前端跨域知識簡介前端跨域
- 搞懂:前端跨域問題JS解決跨域問題VUE代理解決跨域問題原理前端跨域JSVue
- 對前端跨域方案的認知總結前端跨域
- 前端跨域問題如何解決前端跨域
- 前端常見跨域方案彙總前端跨域
- 前端web:主流跨域方式有哪些?前端Web跨域
- 關於 Laravel 設定跨域的中介軟體整理Laravel跨域
- Vue 前端跨域的解決方案(心得記錄)Vue前端跨域
- 前端解決跨域問題的8種方案前端跨域
- 前端解決跨域問題總結前端跨域
- CROS跨域請求設定,偏重前端ROS跨域前端
- jQuery Ajax 跨域前端實現登入jQuery跨域前端
- 前端跨域請求原理及實踐前端跨域
- vue2.0前端跨域方法筆記Vue前端跨域筆記
- 前端常見跨域解決方案(全)前端跨域
- 前端跨域問題及其解決方案前端跨域
- 前端怎麼解決跨域問題前端跨域
- JavaScript跨域(1):什麼是跨域,如何跨域JavaScript跨域
- 跨域問題(普通跨域和springsecurity跨域)跨域SpringGse