怎么解決js跨域問題

192次閱讀

共計 3499 個字符，預計需要花費 9 分鐘才能閱讀完成。

這篇文章主要介紹怎么解決 js 跨域問題，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

Js 跨域問題是 web 開發人員最常碰到的一個問題之一。所謂 js 跨域問題，是指在一個域下的頁面中通過 js 訪問另一個不同域下的數據對象，出于安全性考慮，幾乎所有瀏覽器都不允許這種跨域訪問，這就導致在一些 ajax 應用中，使用跨域的 web service 會成為一個問題。解決 js 跨域問題，目前在客戶端和服務端都有一些現成的解決方案，但這些方案并不能解決所有問題。下面我們先來看下有哪些常用的解決方案，并針對空間產品對跨域問題的需求給出一個 space 自己的解決方案，希望能對其他產品組有借鑒意義。
客戶端解決方案
如何在客戶端解決 js 跨域問題幾乎是所有 web 開發人員會首先考慮的。目前最常用的方法有 2 種：設置 document.domain、通過 script 標簽加載。
設置 document.domain
采用這種方法的前提是跨域請求涉及的兩個頁面必須屬于一個基礎域（例如都是 xxx.com，或是 xxx.com.cn），使用同一協議（例如都是 http）和同一端口（例如都是 80）。例如，aaa.xxx.com 里面的一個頁面需要調用 bbb.xxx.com 里的一個對象，則將兩個頁面的 document.domain 都設置為 xxx.com，就可以實現跨域調用了。另外，需要注意的是，這種方式只能用在父、子頁面之中，即只有在用 iframe 進行數據訪問時才有用。
通過 script 標簽加載
對于瀏覽器來說，script 標簽的 src 屬性所指向資源就跟 img 標簽的 src 屬性所指向的資源一樣，都是一個靜態資源，瀏覽器會在適當的時候自動去加載這些資源，而不會出現所謂的跨域問題。這樣我們就可以通過該屬性將要訪問的數據對象引用進當前頁面而繞過 js 跨域問題。例如，在 space 的我的空間項目中，需要在 hi 域下管理中心頁面中隨機推薦幾個熱門模塊給用戶，由于熱門模塊的相關信息都在 act 域下的 php 模塊中維護，如果直接在 hi 域下通過 ajax 請求去獲取 act 域下的推薦模塊列表相關信息就出現 js 跨域問題。解決這個問題的最簡單方法就是，在 hi 域下通過 script 標簽去訪問 act 域提供的這個 http 接口:
script type=”text/javascript”src=http://www.2cto.com/kf/201109/”http://act.hi.baidu.com/widget/recommend”script
當然，前提是 act 域的這個 http 接口必須是返回一段 js 腳本，如一個 json 對象數組定義的腳本：
modlist = [
{“modname”:“mod1”, “usernum”: 200,“url”:”/widget/info/1”},
{“modname”:”mod2”, “usernum”: 300,”url”:”/widget/info/2”},
…
];
但 script 標簽也有一定的局限性，并不能解決所有 js 跨域問題。script 標簽的 src 屬性值不能動態改變以滿足在不同條件下獲取不同數據的需求，更重要的是，不能通過這種方式正確訪問以 xml 內容方式組織的數據。
服務端解決方案
從上面的說明可以看到，客戶端的解決方案局限性太大，而且對于 ajax 跨域請求，無論兩個域是否屬于同個基礎域，都無法在客戶端加以解決。也就是說，如果我們要想在 ajax 請求中訪問其他域下的數據，就只能通過服務端進行處理了。服務端的解決方案的基本原理就是，由客戶端將請求發給本域服務器，再由本域服務器的代理來請求數據并將響應返回給客戶端。最常用的服務器解決方案就是利用 web 服務器本身提供的 proxy 功能，如 apache 和 lighttpd 的 mod_proxy 模塊。在百度內部，transmit 的分流功能也可以解決部分跨域問題。但這些方法都有一定的局限性，鑒于安全性等問題的考慮，space 這邊最后開發了一個專門用于處理跨域請求代理服務的 spproxy 模塊，用于徹底解決 js 跨域問題。下面我們將以空間的開放平臺為例，簡單介紹下如何通過 apache 的 mod_proxy、transmit 的分流以及 space 的 spproxy 模塊來解決該跨域問題，并簡單介紹下 spproxy 的一些特性、缺點及下一步的改進計劃。空間在展現每個 UWA 開放模塊之前都必須請求該模塊的 xml 源代碼以進行解析，每個模塊的源代碼文件都是存放在 act 域下的 /ow/uwa 目錄下，那么在用戶空間首頁（hi 域）中請求該 xml 文件時就會存在 js 跨域問題。要解決該問題，只能讓 js 向 hi 域的 web 服務器請求 xml 文件，而 hi 域 web 服務器則通過一定的代理機制（如 mod_proxy、transmit 分流、spproxy）向 act 域的 web 服務器請求文件。
利用 apache 的 mod_proxy 模塊
如果 apache 是 2.0 系列版本，則可以通過在 httpd.conf 文件中增加以下配置加以解決：
ProxyRequests Off
Proxy *
Order deny,allow
Allow from all
/Proxy
ProxyPass /ow/uwa http://act.hi.baidu.com/ow/uwa
其中，ProxyRequests 指令關閉了 mod_proxy 的正向代理功能而啟用反向代理功能，Proxy 指令使得該配置對所有訪問生效，ProxyPass 指令使得對本域的 /ow /uwa 目錄下的任何資源的訪問都會在內部被轉換為一個對 act.hi.baidu.com 域下的 /ow/uwa 目錄下對應資源的代理請求。這樣，js 就可以直接通過訪問 http://hi.baidu.com/ow/uwa/0/1/0/10001.xml 獲取位于 act 域下的 /ow/uwa/0/1/0/ 目錄下的 10001.xml 文件。
如果 apache 是經過百度各產品線修改過的 1.3 版本，則需要 mod_proxy 和 mod_rewrite 模塊一起配合來達到同樣的目的。首先需要在 httpd.conf 中增加以下 Location 指令：
Location /ow/uwa
SetHandler proxy-server
order allow,deny
Allow from all
/Location
這樣，對于本域下的 /ow/uwa 目錄下的任何資源的訪問都會首先由 proxy-server 這個 handler（mod_proxy 模塊內部定義的一個 handler）來處理，但光有這段配置還不行，因為還不 proxy-server 還不知道應該怎么處理，僅僅知道需要自己處理而已。這時還需要在配置段中增加一個 rewrite 規則：
RewriteRule ^/ow/uwa/(.*)$ http://act.hi.baidu.com/ow/uwa/$1?%{QUERY_STRING} [P,L]
Rewrite 規則最后的[P,L] 表明該 rewrite 是通過 mod_proxy 代理過去，而不是通過外部重定向過去。如果去掉 P 標志，即采用以下 rewrite 規則：
RewriteRule ^/ow/uwa/(.*)$ http://act.hi.baidu.com/ow/uwa/$1?%{QUERY_STRING} [L]
則響應返回給客戶端時標明的資源 uri 將是重定向后的 uri，在我們的例子中就是 act.hi.baidu.com 域的 uri，則瀏覽器仍然會出現 js 跨域問題。以上只是對 apache 的 proxy 功能的簡單應用，更好更強大的介紹可以參考資料【1】和【2】。Mod_proxy 雖然強大，但我們并沒有用它來解決跨域問題。首先，要使用它必須要求我們的每臺前端機器都能夠訪問外網，否則我們就只能將請求代理到其中一臺前端機器上（通過機器名做內網域名進行 rewrite 或代理），而這顯然是不可取的，因為我們的一個域名通常由很多前端機器組成，只代理到其中一臺機器會導致該機器壓力與其他機器相比很不均衡，甚至撐不住壓力，而給所有前端機器都加訪問外網權限又可能會存在一些安全性策略問題（具體原因不清楚，但 op 和 sa 顯然是不會贊同這種做法）。其次，由于 apache 本身并沒有很好的防 ddos*** 機制，一旦有人通過代理去 *** 目標域（比如說我們的競爭對手的網站），則在目標域的 web 服務器上看來，*** 者就成了我們了，這樣的事情發生時，我們就百口莫辯，跳進黃河也洗不清了。