JavaScript跨域

　　因爲同源策略的限制，JavaScript跨域的問題，一直是一個比較棘手的問題，爲了解決頁面之間的跨域通訊，你們煞費苦心，研究了各類跨域方案。以前也有小網同窗分享過一篇「跨域，再也不糾結」 開始照着嘗試時仍是有些不夠明白的地方，深刻了解以後，這裏給你們補充一點更具體的作法。

　　先來看看哪些狀況下才存在跨域的問題：

　　其中編號六、7兩種狀況同屬於主域名相同的狀況，能夠設置domain來解決問題，今天就不討論這種狀況了。 對於其餘跨域通訊的問題，我想又能夠分紅兩類：

　　其一（第一種狀況）是a.com下面的a.js試圖請求b.com下某個接口時產生的跨域問題。

　　其二（第二種狀況）是當a.com與b.com下面的頁面成父子頁面關係時試圖互相通訊時產生的跨域問題，典型的應用場景如a.com/a.html使用iframe內嵌了b.com/b.html，你們都知道a.html內的js腳本試圖訪問b.html時是會被拒絕的，反之亦然。

　　第一種狀況，目前主流的方案是JSONP，高版本瀏覽器支持html5的話，還可使用XHR2支持跨域通訊的新特性。

　　第二種狀況，目前主要是經過代理頁面或者使用postMessageAPI來作，這也是今天要討論的話題。第二種狀況，有這樣一些相似的案例：a.com/a.html使用iframe內嵌了b.com/b.html，如今但願iframe的高度能自動適應b.html的高度，使iframe不要出現滾動條。咱們都知道跨域了，a.html是沒辦法直接讀取到b.html的高度的，b.html也沒辦法把本身的高度告訴a.html。 直接說能夠用代理頁面的方法搞定這個問題吧，可是怎麼代理法，先來看下面這張圖：

　　b.html與a.html是不能直接通訊的。咱們能夠在b.html下面再iframe內嵌一個proxy.html頁面，由於這個頁面是放在a.com下面的，與a.html同域，因此它實際上是能夠和a.html直接通訊的，假如a.html裏面有定義一個方法_callback，在proxy.html能夠直接top._callback()調用它。可是b.html自己和proxy.html也是不能直接通訊的，所謂代理頁面的橋樑做用怎麼實現呢? b.html內嵌proxy.html是經過一段相似下面這樣的代碼： <iframe id=」proxy」 src=」a.com/proxy.html」 name=」proxy」 frameborder=」0″ width=」0″ height=」0″></iframe> 這個iframe的src屬性b.html是有權限控制的。若是它把src設置成a.com/proxy.html?args=XXX,也就是給url加一個查詢字符串，proxy.html內的js是能夠讀取到的。對的，這個url的查詢字符串就是b.html和proxy.html之間通訊的橋樑，美中不足的是每次通訊都要重寫一次url形成一次網絡請求，這有時會對服務器及頁面的運行效率產生很大的影響。同時因爲參數是經過url來傳遞的，會有長度和數據類型的限制，蒐集的資料顯示：

• IE瀏覽器對URL的長度現限制爲2048字節。
• 360極速瀏覽器對URL的長度限制爲2118字節。
• Firefox(Browser)對URL的長度限制爲65536字節。
• Safari(Browser)對URL的長度限制爲80000字節。
• Opera(Browser)對URL的長度限制爲190000字節。
• Google(chrome)對URL的長度限制爲8182字節。

　　上面的方法，經過迂迴戰術實現了b.html跟a.html通訊，可是倒過來，a.html怎麼跟b.html通訊呢?嵌入在b.html裏面的proxy.html能夠用top快速的聯繫上a.html，可是要想讓a.html找到proxy.html就不容易了，夾在中間的 b.html生生把它們分開了，a.html無法讓b.html去找到proxy.html而後返回給它。只能採用更迂迴的戰術了。 順着前面b.html到a.html的通訊過程，逆向的想一下，雖然a.html沒有辦法主動找到proxy.html，可是proxy.html能夠反過來告訴a.html它在哪裏： 在proxy.html加這麼一段腳本：

　　也就是必須由proxy.html先主動發送一個消息給a.html，a.html獲得proxy.html頁面window的引用，就能夠反過來向它發送請求了。 如今a.html能夠把消息發給proxy.html了，可是proxy.html怎麼把消息轉送到b.html？彷佛這纔是難點，由於它們之間才真正有着「跨域」這一道鴻溝。 這回咱們再也不用前面那個iframe內嵌代理頁面的方法再在proxy.html內嵌一個b.com下面的代理頁面了，這樣實在會給人感受嵌的太深了，四層。可是爲了跨越這道鴻溝，b.com下面也加一個代理頁面是免不的。不過如今咱們要利用一下window.name。window.name有一個特性，就是頁面在同一個瀏覽器窗口（標籤頁）中跳轉時，它一直存在並且值不會改變。好比咱們在a.html中設置了window.name=」a」，而後location.href=」http://b.com/b.html」跳轉後，b.html能夠讀取window.name的值爲」a」;並且window.name的值長度通常能夠到達2M，ie和firefox甚至能夠達到32M，這樣的存儲容量，足夠利用起來作跨域的數據傳遞了。好吧，咱們如今要作的就是當proxy.html拿到a.html發送過來的數據後把這個數據寫入window.name中，而後跳轉到b.com下面的代理頁面，咱們這裏假設是bproxy.html。bproxy.html讀取到window.name值後，通知給它父頁面b.html就簡單了。咱們再來看這個過程能夠用圖大概示意一下：

　　圖例中綠色的雙向箭頭表示能夠通訊，橙色的雙向箭頭表示不能直接通訊。 最後咱們簡單看一下雙向通訊的實測效果：

　　b.html每次加載的時候都先給a.html發一個」鏈接請求」，讓a.html能夠找到proxy.html。因此頁面第一次加載的時候會產生三個請求：

　　每次b.html向a.html發送消息的時候會產生一個請求：

　　每次a.html向b.html發送消息的時候會產生兩個請求，其中一個是a.com/proxy.html向b.com/bproxy.html跳轉產生的，另外一個是b.html從新向a.html發起「鏈接請求」時產生的：

　　最後簡單看一下實測的幾個測試頁面代碼：

　　代碼片斷一，a.com/a.html:　　 

　　代碼片斷二，a.com/proxy.html:

　　代碼片斷三，b.com/b.html:

　　代碼片斷四，b.com/bproxy.html:

　　好吧，如今我必須把話鋒調轉一下了。前面講的這麼多，也只是拋出來一些以前咱們可能會採用的跨域通訊方法，事實上代理頁面、url傳參數和window.name、甚至還有一些利用url的hash值的跨域傳值方法，都能百度到很多相關資料。但它們都逃不開代理頁面，也就不可避免的要產生網絡請求，而事實上這並非咱們的本意，咱們本來但願它們可以直接在客戶端通訊，避免沒必要要的網絡請求開銷——這些開銷，在訪問量超大的站點可能會對服務器產生至關大的壓力。那麼，有沒有更完美一點的替代方案呢？ 必須給你們推薦postMessage。postMessage 正是爲了知足一些合理的、不一樣站點之間的內容能在瀏覽器端進行交互的需求而設計的。利用postMessage API實現跨域通訊很是簡單，咱們直接看一下實例的代碼：

　　代碼片斷五，A.com/a.html：　　 

　　代碼片斷六，b.com/b.html：

　　代碼的關鍵是message事件是一個擁有data（數據）和origin(來源)屬性的DOM事件。data屬性是發送的實際數據，origin屬性是發送來源。Origin屬性很關鍵，有了這個屬性，接收方能夠輕易的忽略掉來自不可信源的消息，也就能有效避免跨域通訊這個開口給咱們的源安全帶來的隱患。接口很強大，因此代碼很簡單。咱們能夠抓包看一下，這個通訊過程徹底是在瀏覽器端的，沒有產生任何的網絡請求。同時這個接口目前已經獲得了絕大多數瀏覽器的支持，包括IE8及以上版本，參見下面的圖表：

　　可是爲了覆蓋ie6等低版本瀏覽器，咱們完整的方案裏面仍是要包含一下兼容代碼，就是最開始介紹的代理頁面的方法了，但必須是以postMessage爲主，這樣即使最後會有某些瀏覽器由於這種通訊產生一些網絡請求，比例也是很是低的了。

http://kb.cnblogs.com/page/198884/