資訊專欄INFORMATION COLUMN
摘要：同源策略及跨域訪問同源策略同源策略約束了兩個域之間資源的加載方式，是一個很重要的安全機(jī)制用來隔離那些有潛在安全隱患的文檔。
同源策略及跨域訪問 同源策略
同源策略（Same-origin policy）約束了兩個域之間資源的加載方式，是一個很重要的安全機(jī)制用來隔離那些有潛在安全隱患的文檔。
何為源（orgin）一個源由一個URL的協(xié)議（protocol）、主機(jī)（host）和端口（port）進(jìn)行定義。如果兩個頁面擁有相同的協(xié)議、主機(jī)和端口一致的話，我們就可以稱它們?yōu)橥础Ｏ旅娴谋砀癖容^了不同的URL跟http://store.company.com/dir/page.html這個URL的同源情況：
| URL | 是否同源 | 理由 |
|---|---|---|
| http://store.company.com/dir2... | 是 | |
| http://store.company.com/dir/... | 是 | |
| https://store.company.com/sec... | 否 | 協(xié)議不同 |
| http://store.company.com:81/d... | 否 | 端口不同 |
| http://news.company.com/dir/o... | 否 | 主機(jī)不同 |
同源策略控制了兩個源之間的交互，例如你使用XMLHttpRequest發(fā)起一個請求，或者使用元素加載一張圖片，就會產(chǎn)生兩個源之間的交互。而當(dāng)兩個源不相同時，有些交互會被允許，而有些則不被允許。而不允許的情況，就是我們常說的跨域訪問問題。那什么情況下不同源的交互會被允許，什么情況下又不被允許呢？大致可以分為如下的情況：
鏈接、跳轉(zhuǎn)和表單提交這些在跨域的情況下都是被允許的。例如調(diào)用支付寶接口進(jìn)行支付就是典型的跨域表單提交的場景，這種跨域的調(diào)用是被允許的。但是這個很容易被利用來進(jìn)行CSRF攻擊，所以我們的表單提交需要做好這方面的防護(hù)。
跨域的資源內(nèi)嵌是被允許的。下面是一些資源內(nèi)容的例子：
使用加載Javascript。只有同源的腳本在語法錯誤時會顯示錯誤信息。
使用加載CSS。跨源的CSS文件要求使用正確的Content-Type 響應(yīng)頭。
使用加載圖片。
使用和加載媒體文件。
使用 、和加載插件。
使用 @font-face加載字體。有些瀏覽器允許加載跨域的字體，有些則不允許。
使用 和
然后在http://sub.example.com/iframe.html頁面對父頁面的背景色進(jìn)行修改：
......
由于兩個頁面不同源，所以子頁面對父頁面的操作被禁止，例如在Firefox上你會看到以下的報錯：
Error: Permission denied to access property "document"
不同源之間的XMLHttpRequest調(diào)用（也就是我們常說ajax調(diào)用）是不被允許的，這個也是我們最常遇到的跨域訪問場景。例如我們在http://example.com/index.html頁面進(jìn)行如下的ajax調(diào)用：
var xhr = new XMLHttpRequest();
var url = "http://otherexample.com/api/get-data";
xhr.open("GET", url, true);
xhr.onreadystatechange = handler;
xhr.send();
在Firefox下會報如下錯誤：
已攔截跨源請求：同源策略禁止讀取位于 http://otherexample.com/api/get-data 的遠(yuǎn)程資源。（原因：CORS 頭缺少 "Access-Control-Allow-Origin"）。
跨域訪問的解決方案
修改源
一個頁面的源是可以修改的，修改的方法很簡單，就是通過Javascript腳本設(shè)置document.domain的值。舉個例子，我們在頁面http://store.company.com/dir/other.html執(zhí)行下面的代碼：
document.domain = "company.com";
那么這個頁面的域?qū)?b>store.company.com變成company.com，后面在判斷是否同源的時候，主機(jī)將會使用company.com這個值，而不是store.company.com。
那是不是修改域后就能跟同域的頁面進(jìn)行交互呢。答案是否定的。例如，如果你在頁面中通過iframe嵌入http://company.com/dir/page.html這個頁面，然后通過javascript去跟這個頁面交互，你會發(fā)現(xiàn)瀏覽器會報錯，就跟我們之前那個例子一樣。按照上面的源的定義，這時候兩個頁面應(yīng)該是同源的，為什么呢？因為修改document.domain會導(dǎo)致端口號被設(shè)為null。所以另外一個頁面也需要把document.domain修改為相同的值，這樣兩個頁面的主機(jī)和端口就一致了，可以進(jìn)行互相的訪問了。
既然源可以修改，那么是不是就解決了我們的跨域問題呢？明顯沒這么簡單。首先，這種方法是有很大限制條件的，document.domain這個值只能修改為這個頁面的當(dāng)前域或者當(dāng)前域的超級域。所以，這個方法只能解決同一超級域下的頁面跨域問題。其次，它的使用場景也很有限，因為它需要頁面執(zhí)行Javascript腳本，所以也就是說一般只能應(yīng)用于頁面跟頁面的交互，例如訪問ifame頁面或者window.open打開的頁面等等。所以如果你想用來解決ajax之類的跨域調(diào)用，這個方法就無能為力了。
使用代理
使用代理也是解決跨域訪問的一個方法。上面修改document.domain的方法只能用來訪問子域名的頁面，無法訪問不同域的頁面，而使用代理則沒有這個問題。
例如我們有一個頁面http://example.com/，需要訪問http://otherexample.com/這個頁面，我們不直接對這個頁面進(jìn)行訪問，而是通過請求另外一個同源的頁面，這個頁面在后端通過代理服務(wù)器把請求轉(zhuǎn)發(fā)到http://otherexample.com/，獲取數(shù)據(jù)并返回給客戶端。
另外，這個方法同樣可以用于解決ajax的跨域訪問問題。
JSONP
JSONP也被經(jīng)常用來解決ajax的跨域調(diào)用問題。JSONP請求并不是通過XMLHttpRequest發(fā)起，而是使用
然后接口獲取到callback函數(shù)名后，把原來返回的數(shù)據(jù)作為函數(shù)的參數(shù)，最終返回如下的Javascript：
myFunction({"id": "123", "name": "Captain Jack Sparrow"});
然后myFunction就會執(zhí)行，達(dá)到了調(diào)用的目的。
這個方法在大多數(shù)情況下都很有用，但是它也有它的局限。一是它需要后端的配合，因為后端的接口需要根據(jù)約定的參數(shù)獲取回調(diào)函數(shù)名，然后跟返回數(shù)據(jù)進(jìn)行拼接，最后進(jìn)行響應(yīng)。二是它只能進(jìn)行異步的調(diào)用，因為它的原理是通過動態(tài)生成
閱讀需要支付1元查看
<