终端跨域访问

㈠ 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语言安全限制中的同源策略造成的。
简单来说,同源策略是指一段脚本只能读取来自同一来源的窗口和文档的属性,这里的同一来源指的是主机名、协议和端口号的组合。