終端跨域訪問

㈠ firefox 47.0.1支持ajax 跨域請求嗎

不支持，火狐在20版本附近就已經不允許跨域的ajax的請求了。
因為這樣極易導致跨域注入，出現安全問題，對終端用戶，尤其是普通用戶帶來安全隱患。

㈡ 跨域訪問指定URL

Silverlight
警告：無法定位位於「<URL>」的跨域策略

在指定的 URL 未找到服務的跨域策略文件。

如果 Silverlight 版本 2 應用程序需要訪問其他域中的服務，該服務必須顯式選擇允許跨域訪問。通過選擇，服務可以確認它公開的操作可以由 Silverlight 2 控制項安全地調用，而不會損壞該服務存儲的數據的結果。

使用 clientaccesspolicy.xml 文件以允許跨域訪問
創建允許訪問該服務的 clientaccesspolicy.xml 文件。以下配置允許從任何其他域訪問 clientaccesspolicy.xml 文件所在域的所有資源：

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
如果要只從一個其他域（如 http://contoso.com）進行訪問，clientaccesspolicy.xml 應包含以下配置：

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="http://contoso.com"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
將 clientaccesspolicy.xml 文件保存到服務所在的域的根。例如，如果服務位於 http://fabrikam.com 中，該文件必須位於 http://fabrikam.com/clientaccesspolicy.xml。

通過從您的應用程序調用服務來測試是否允許進行訪問。

使用 crossdomain.xml 文件以允許跨域訪問
創建包含以下配置的 crossdomain.xml 文件。必須將該文件配置為允許從任何其他域訪問服務，否則它無法被 Silverlight 2 識別。

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM _
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
將 crossdomain.xml 文件保存到服務所在的域的根。例如，如果服務位於 http://fabrikam.com 中，該文件必須位於 http://fabrikam.com/crossdomain.xml。

通過從您的應用程序調用服務來測試是否啟用了服務。

㈢ 什麼叫做跨域訪問，求大神解答

如果在A網站中，我們希望使用Ajax來獲得B網站中的特定內容
如果A網站與B網站不在同一個域中，那麼就出現了跨域訪問問題
Ajax的跨域訪問問題是現有的Ajax開發人員比較常遇到的問題
一般都會用jsoncallback方法來解決
你可以理解為兩個域名之間不能跨過域名來發送請求或者請求數據，否則就是不安全的
希望能幫助到你

㈣ 跨域有哪幾種方式

跨源資源共享

通過 XHR 實現 Ajax 通信的一個主要限制,來源於跨域安全策略。默認情況下,XHR 對象只能訪 問與包含它的頁面位於同一個域中的資源。這種安全策略可以預防某些惡意行為。但是,實現合理的跨 域請求對開發某些瀏覽器應用程序也是至關重要的。

CORS(Cross-Origin Resource Sharing,跨源資源共享)是 W3C 的一個工作草案,定義了在必須訪 問跨源資源時,瀏覽器與伺服器應該如何溝通。CORS 背後的基本思想,就是使用自定義的 HTTP 頭部 讓瀏覽器與伺服器進行溝通,從而決定請求或響應是應該成功,還是應該失敗。

比如一個簡單的使用 GET 或 POST 發送的請求,它沒有自定義的頭部,而主體內容是 text/plain。在 發送該請求時,需要給它附加一個額外的 Origin 頭部,其中包含請求頁面的源信息(協議、域名和端 口),以便伺服器根據這個頭部信息來決定是否給予響應。下面是 Origin 頭部的一個示例:

這個例子通過查詢地理定位服務來顯示你的 IP 地址和位置信息。
JSONP 之所以在開發人員中極為流行,主要原因是它非常簡單易用。與圖像 Ping 相比,它的優點 在於能夠直接訪問響應文本,支持在瀏覽器與伺服器之間雙向通信。不過,JSONP 也有兩點不足。

• 首先,JSONP 是從其他域中載入代碼執行。如果其他域不安全,很可能會在響應中夾帶一些惡意代碼,而此時除了完全放棄 JSONP 調用之外,沒有辦法追究。因此在使用不是你自己運維的 Web 服務時, 一定得保證它安全可靠。

  
  

• 其次,要確定 JSONP 請求是否失敗並不容易。雖然 HTML5 給<script>元素新增了一個 onerror 事件處理程序,但目前還沒有得到任何瀏覽器支持。為此,開發人員不得不使用計時器檢測指定時間內是否接收到了響應。但就算這樣也不能盡如人意,畢竟不是每個用戶上網的速度和帶寬都一樣。

  
  

參考：javascript高級程序設計第21章

㈤ 如何解決跨域問題

關於跨域名問題還是問題么，這方面的解決實踐非常多，今天我就舊話重提把我所知道的通過幾個應用場景來分別總結一下（轉帖請註明出處：http://blog.csdn.net/lenel）

先說明一點：我說的某某域名在您的控制下的意思是這個域名下的網頁由您來負責開發內部的JavaScript
場景一：將bbs.xxx.com的頁面用iframe嵌入到www.xxx.com的中，如何在iframe內外使用js通信（轉帖請註明出處：http://blog.csdn.net/lenel）
一級域名都是xxx.com 這個域名一定是在您的控制下，所以你只要在兩個頁面中同時升級域名即可
在父窗口和iframe內部分別加上js語句：document.domain="xxx.com";
之後2個頁面就等於在同一域名下，通過window.parent oIframe.contentDocument就可以相互訪問，進行無障礙的JS通信
在新浪、淘寶等很多頁面都能找到這樣的語句。不過document.domain不可以隨便指定，只能向上升級，從bbs.xxx.com升級到yyy.com肯定會出錯

場景二：將www.yyy.com的頁面用iframe嵌入到www.xxx.com的中，兩個域名都在您的控制下，如何在iframe內外進行一定的數據交流（轉帖請註明出處：http://blog.csdn.net/lenel）
你可以通過相互改變hash值的方式來進行一些數據的通信

這里的實現基於如下技術要點：
1、父窗口通過改變子窗口的src中的hash值把一部分信息傳入，如果src只有hash部分改變，那麼子窗口是不會重新載入的。
2、
子窗口可以重寫父窗口的location.href，但是注意這里子窗口無法讀取而只能重寫location.href所以要求前提是您控制兩個域名，知
道當前父窗口的location.href是什麼並寫在子窗口內，這樣通過parent.location.href =
"已知的父窗口的href"+"#"+hash。這樣父窗口只有hash改變也不會重載。
3、上面兩步分別做到了兩個窗口之間的無刷新數據通知，
那麼下面的來說如何感知數據變化。標准中沒有相關規定，所以當前的任意瀏覽器遇到location.hash變化都不會觸發任何javaScript事
件，也就是說您要自己寫監聽函數來監視loaction.hash的值的變化。做法是通過setTimeout或者setInterval來寫一個監聽函
數每20-100ms查看一下hash是否變化，如果變化了驅動js根據新的數據做想做的事情。

這種實現的一些分析：
1、信息通道是雙向的，當然會兼容單向，如果只是父窗口向子窗口通知數據，只需要子窗口寫hash監聽，反之亦然。
2、局限性也是頗大，因為這種通信的前提是雙方知道對方的location.href。如果父窗口帶有動態的location.search也就是查詢參數，那麼子窗口的處理上就比較困難，需要把父窗口的location.search作為傳遞信息的一部分告知子窗口。
3、另外的困擾會有瀏覽器帶給你，IE之外的瀏覽器遇到hash的改變會記錄歷史，這樣你在處理前進後退的時候會非常頭疼

場景三：將www.yyy.com的頁面用iframe嵌入到www.xxx.com的中，只有被嵌入的yyy.com在您的控制下，如何在iframe內外進行一定的交流
真實場景：google adsence的一個需求，你希望google發現您的頁面不能匹配出相關性非常好的按點擊付費廣告時，你希望google的廣告iframe能夠隱藏。
google的廣告iframe在google域下顯然不能把自己隱藏掉，那麼怎麼辦呢？
1、google會提供給你一個html頁面
2、您將這個頁面放置在您的域名下，並告訴google它的位置
3、當google發現沒有很好的廣告時，會將子窗口的loaction重定向到您的那個頁面下，這樣您的頁面因為同域名就可以訪問父頁面來隱藏自己了
是不是很巧的方法？

場景四：您是內容發布商，如何改造介面，讓其他域名下的頁面可以從瀏覽器端出發獲得您的數據
我們知道ajax的xmlHttpRequest()說到底是一個無刷新請求伺服器數據的輔助工具，但是xmlHttpRequest並不能跨域名請求數據，在某些情況下成了極大的限制。
但是我們如果通過其他方式完成無刷新請求數據不也可以么，我們用Dom方法操作動態JS腳本請求來做這件事。
//創建一個腳本節點
var oScript = document.createElement('script');
//指定腳本src src可以指向任意域名
//注意src不再指向靜態js，而是帶著查詢參數指向一個動態腳本廣播服務。
oScript.src = "http://yyy.com/query.php?"+yourQueryString;

//如果指定了charset 同時還可以解決xmlHttpRequest另一大困擾 亂碼問題

//oScript.charset = "utf-8";
//通過Dom操作把這個新的節點加入到文檔當中
document.getElementsByTagName("head")[0].appendChild(oScript);

這樣只要query.php的輸出是可執行的javaScript腳本，比如：djsCallBack（{jsondata}）;
當他從伺服器返回後就會自動執行,你可以方便的用json方式來做數據傳遞了。
要注意，您的腳本請求最好帶上時間戳，避免瀏覽器緩存造成取回數據實時性下降。

如果您是數據提供者，您可以要求數據索取者在查詢參數中提供回調函數名，比如query.php?callback=myDataHandler&key=...?
這樣您就可以根據參數來提供給他myDataHandler({jsondata}),這樣不同的數據索取者都會得到自定義的正確的非同步回調。

進一步發展，可以做一個統一的從xml到動態json的數據轉化伺服器，脫離數據的實際意義，針對任何xml介面都可以作為轉化後提供給客戶端直接訪問。
這樣就不用針對單獨xml數據服務，為了跨域名而做各自的後台數據抓取轉化服務。

用動態腳本傳數據功能非常強大，去年我最先在YAHOO的站點上看到這樣的應用，讓人眼前一亮。

總結總結：
第一種場景，相應的處理辦法有這非常好的效果，可以說完全解決了問題。
第二種場景，相應的處理辦法具有一定的跨域數據交流功效，具有相當大的局限，並不適合在復雜業務流程中應用，實際上我也確實也沒看到過基於此的大規模應用。
第三種場景，相應的處理辦法比較巧妙，雖然redirect之後就不幹你什麼事了，但如果你是google一樣面向眾多域名的內容提供商，也是個不錯的解決思路。
第四種場景，相應的處理辦法非常強大，對比Ajax可以看到，跨域名沒問題，無刷新沒問題，本身又是非同步的，JSON比xml快的多，同時解決亂碼問題，只是請求都是Get方式的，不能做Post方式的請求。多一種武器自然可以從容選擇了

㈥ 如何配置解決跨域的問題

方法/步驟

伺服器端對於CORS的支持，是通過設置Access-Control-Allow-Origin來進行的。如果瀏覽器檢測到相應的設置，就可以允許Ajax進行跨域的訪問
打開控制面板，選擇管理工具

選擇iis

右鍵單擊自己的網站，選擇瀏覽

打開網站所在目錄
用記事本打開web.config文件添加如圖的一句話，保存，重啟網站就好了，客戶端直接用html5編輯，不用任何設置

㈦ 怎麼解決伺服器間的跨域問題

服務端的解決方案的基本原理就是，由客戶端將請求發給本域伺服器，再由本域伺服器的代理來請求數據並將響應返回給客戶端。
最常用的伺服器解決方案就是利用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伺服器請求文件

㈧ 什麼是跨域訪問

JS本身不允許跨域訪問，需要通過跨域處理才行，但是谷歌瀏覽器有一項允許跨域功能可以開啟。方法如下：

1.選擇谷歌瀏覽器，右鍵--屬性。

㈨ 為什麼超鏈接可以實現跨域訪問呢

1.什麼是跨域
經常會在頁面上使用ajax請求訪問其他伺服器的數據,此時,客戶端會出現跨域問題。
跨域問題是由於javascript語言安全限制中的同源策略造成的。
簡單來說,同源策略是指一段腳本只能讀取來自同一來源的窗口和文檔的屬性,這里的同一來源指的是主機名、協議和埠號的組合。