JavaScript跨域總結與解決辦法 JavaScript跨域總結與解決辦法

JavaScript跨域總結與解決辦法

本文來自網絡(http://f2e.me/200904/cross-scripting/,該網址已不能訪問),僅做我的讀書筆記之用,並稍做修改和補充。javascript

什麼是跨域

JavaScript出於安全方面的考慮,不容許跨域調用其餘頁面的對象。但在安全限制的同時也給注入iframe或是ajax應用上帶來了很多麻煩。這裏把涉及到跨域的一些問題簡單地整理一下:css

首先什麼是跨域,簡單地理解就是由於JavaScript同源策略的限制,a.com 域名下的js沒法操做b.com或是c.a.com域名下的對象。更詳細的說明能夠看下錶:html

URL 說明 是否容許通訊
http://www.a.com/a.js
http://www.a.com/b.js
同一域名下 容許
http://www.a.com/lab/a.js
http://www.a.com/script/b.js
同一域名下不一樣文件夾 容許
http://www.a.com:8000/a.js
http://www.a.com/b.js
同一域名,不一樣端口 不容許
http://www.a.com/a.js
https://www.a.com/b.js
同一域名,不一樣協議 不容許
http://www.a.com/a.js
http://70.32.92.74/b.js
域名和域名對應ip 不容許
http://www.a.com/a.js
http://script.a.com/b.js
主域相同,子域不一樣 不容許
http://www.a.com/a.js
http://a.com/b.js
同一域名,不一樣二級域名(同上) 不容許(cookie這種狀況下也不容許訪問)
http://www.cnblogs.com/a.js
http://www.a.com/b.js
不一樣域名 不容許
特別注意兩點:
第一,若是是協議和端口形成的跨域問題「前臺」是無能爲力的,
第二:在跨域問題上,域僅僅是經過「URL的首部」來識別而不會去嘗試判斷相同的ip地址對應着兩個域或兩個域是否在同一個ip上。
「URL的首部」指window.location.protocol +window.location.host,也能夠理解爲「Domains, protocols and ports must match」。

接下來簡單地總結一下在「前臺」通常處理跨域的辦法,後臺proxy這種方案牽涉到後臺配置,這裏就不闡述了,有興趣的能夠看看yahoo的這篇文章:《JavaScript: Use a Web Proxy for Cross-Domain XMLHttpRequest Callshtml5

一、document.domain+iframe的設置

對於主域相同而子域不一樣的例子,能夠經過設置document.domain的辦法來解決。 具體的作法是能夠在http://www.a.com/a.html和http://script.a.com/b.html兩個文件中分別加上 document.domain = ‘a.com’;而後經過a.html文件中建立一個iframe,去控制iframe的contentDocument,這樣兩個js文件之間就能夠 「交互」了。固然這種辦法只能解決主域相同而二級域名不一樣的狀況,若是你異想天開的把script.a.com的domian設爲alibaba.com 那顯然是會報錯地!代碼以下:java

www.a.com上的a.htmlnode

document.domain = 'a.com';
var ifr = document.createElement('iframe');
ifr.src = 'http://script.a.com/b.html';
ifr.style.display = 'none';
document.body.appendChild(ifr);
ifr.onload = function(){
    var doc = ifr.contentDocument || ifr.contentWindow.document;
    // 在這裏操縱b.html
    alert(doc.getElementsByTagName("h1")[0].childNodes[0].nodeValue);
};

script.a.com上的b.htmlweb

document.domain = 'a.com';

這種方式適用於{www.kuqin.com, kuqin.com, script.kuqin.com, css.kuqin.com}中的任何頁面相互通訊。ajax

備註:某一頁面的domain默認等於window.location.hostname。主域名是不帶www的域名,例如a.com,主域名前面帶前綴的一般都爲二級域名或多級域名,例如www.a.com實際上是二級域名。 domain只能設置爲主域名,不能夠在b.a.com中將domain設置爲c.a.com。chrome

問題:
一、安全性,當一個站點(b.a.com)被攻擊後,另外一個站點(c.a.com)會引發安全漏洞。
二、若是一個頁面中引入多個iframe,要想可以操做全部iframe,必須都得設置相同domain。

二、動態建立script

雖然瀏覽器默認禁止了跨域訪問,但並不由止在頁面中引用其餘域的JS文件,並能夠自由執行引入的JS文件中的function(包括操做cookie、Dom等等)。根據這一點,能夠方便地經過建立script節點的方法來實現徹底跨域的通訊。具體的作法能夠參考YUI的Get Utility編程

這裏判斷script節點加載完畢仍是蠻有意思的:ie只能經過script的readystatechange屬性,其它瀏覽器是script的load事件。如下是部分判斷script加載完畢的方法。

js.onload = js.onreadystatechange = function() {
    if (!this.readyState || this.readyState === 'loaded' || this.readyState === 'complete') {
        // callback在此處執行
        js.onload = js.onreadystatechange = null;
    }
};

三、利用iframe和location.hash

這個辦法比較繞,可是能夠解決徹底跨域狀況下的腳步置換問題。原理是利用location.hash來進行傳值。在url: http://a.com#helloword中的‘#helloworld’就是location.hash,改變hash並不會致使頁面刷新,因此可 以利用hash值來進行數據傳遞,固然數據容量是有限的。假設域名a.com下的文件cs1.html要和cnblogs.com域名下的 cs2.html傳遞信息,cs1.html首先建立自動建立一個隱藏的iframe,iframe的src指向cnblogs.com域名下的 cs2.html頁面,這時的hash值能夠作參數傳遞用。cs2.html響應請求後再將經過修改cs1.html的hash值來傳遞數據(因爲兩個頁面不在同一個域下IE、Chrome不容許修改parent.location.hash的值,因此要藉助於a.com域名下的一個代理iframe;Firefox能夠修改)。同時在cs1.html上加一個定時器,隔一段時間來判斷location.hash的值有沒有變化,一點有變化則獲取獲取hash值。代碼以下:

先是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);
    }
}

a.com下的域名cs3.html

//由於parent.parent和自身屬於同一個域,因此能夠改變其location.hash的值
parent.parent.location.hash = self.location.hash.substring(1);

固然這樣作也存在不少缺點,諸如數據直接暴露在了url中,數據容量和類型都有限等……

四、window.name實現的跨域數據傳輸

文章較長列在此處不便於閱讀,詳細請看 window.name實現的跨域數據傳輸

五、使用HTML5 postMessage

HTML5中最酷的新功能之一就是 跨文檔消息傳輸Cross Document Messaging。 下一代瀏覽器都將支持這個功能:Chrome 2.0+、Internet Explorer 8.0+, Firefox 3.0+, Opera 9.6+, 和 Safari 4.0+ 。 Facebook已經使用了這個功能,用postMessage支持基於web的實時消息傳遞。

otherWindow.postMessage(message, targetOrigin);
otherWindow: 對接收信息頁面的window的引用。能夠是頁面中iframe的contentWindow屬性;window.open的返回值;經過name或下標從window.frames取到的值。
message: 所要發送的數據,string類型。
targetOrigin: 用於限制otherWindow,「*」表示不做限制

a.com/index.html中的代碼:

<iframe id="ifr" src="b.com/index.html"></iframe>
<script type="text/javascript">
window.onload = function() {
    var ifr = document.getElementById('ifr');
    var targetOrigin = 'http://b.com';  // 若寫成'http://b.com/c/proxy.html'效果同樣
                                        // 若寫成'http://c.com'就不會執行postMessage了 ifr.contentWindow.postMessage('I was there!', targetOrigin); }; </script>

b.com/index.html中的代碼:

<script type="text/javascript">
    window.addEventListener('message', function(event){
        // 經過origin屬性判斷消息來源地址
        if (event.origin == 'http://a.com') {
            alert(event.data);    // 彈出"I was there!"
            alert(event.source);  // 對a.com、index.html中window對象的引用
                                  // 但因爲同源策略,這裏event.source不能夠訪問window對象
        }
    }, false);
</script>

參考文章:《精通HTML5編程》第五章——跨文檔消息機制https://developer.mozilla.org/en/dom/window.postmessage

六、利用flash

這是從YUI3的IO組件中看到的辦法,具體可見http://developer.yahoo.com/yui/3/io/
能夠看在Adobe Developer Connection看到更多的跨域代理文件規範:ross-Domain Policy File SpecificationsHTTP Headers Blacklist