js跨域解决方案文档格式.docx

1、 “URL的首部”指 +，也可以理解为“Domains, protocols and ports must match”。 接下来简单地总结一下在“前台”一般处理跨域的办法，后台proxy这种方案牵涉到后台配置，这里就不阐述了，有兴趣的可以看看yahoo的这篇文章：JavaScript: Use a Web Proxy for Cross-Domain XMLHttpRequest Calls 对于主域相同而子域不同的例子，可以通过设置的办法来解决。具体的做法是可以在/和p上的 = &（来自: 小龙文 档网:js跨域解决方案）#39; var ifr = （iframe）; = p / 在这里

2、操纵 alert（h1）0.childNodes0.nodeValue）; ; 上的 = 这种方式适用于, , , 中的任何页面相互通信。 备注：某一页面的domain默认等于。主域名是不带www的域名，例如，主域名前面带前缀的通常都为二级域名或多级域名，例如 其实是二级域名。 domain只能设置为主域名，不可以在中将domain设置为。 问题： 1、安全性，当一个站点（）被攻击后，另一个站点（）会引起安全漏洞。 2、如果一个页面中引入多个iframe，要想能够操作所有iframe，必须都得设置相同domain。虽然浏览器默认禁止了跨域访问，但并不禁止在页面中引用其他域的JS文件，并可以自由

3、执行引入的JS文件中的function（包括操作cookie、Dom等等）。根据这一点，可以方便地通过创建script节点的方法来实现完全跨域的通信。具体的做法可以参考YUI的Get Utility 这里判断script节点加载完毕还是蛮有意思的：ie只能通过script的readystatechange属性，其它浏览器是script的load事件。以下是部分判断script加载完毕的方法。 = = function（） if （! | = loadedcomplete） / callback在此处执行 = = null; ; 不同的域之间，JavaScript只能做很有限的访问和操作，其实我

4、们利用这些有限的访问权限就可以达到跨域通信的目的了。FIM （Fragment Identitier Messaging）就是在这个大前提下被发明的。父窗口可以对iframe进行URL读写，iframe也可以读写父窗口的URL，URL有一部分被称为frag，就是#号及其后面的字符，它一般用于浏览器锚点定位，Server端并不关心这部分，应该说HTTP请求过程中不会携带frag，所以这部分的修改不会产生HTTP请求，但是会产生浏览器历史记录。FIM的原理就是改变URL的frag部分来进行双向通信。每个window通过改变其他 window的location来发送消息，并通过监听自己的URL的变化

5、来接收消息。这个方式的通信会造成一些不必要的浏览器历史记录，而且有些浏览器不支持onhashchange事件，需要轮询来获知URL的改变，最后，URL在浏览器下有长度限制，这个制约了每次传送的数据量。 这个办法比较绕，但是可以解决完全跨域情况下的脚步置换问题。原理是利用 来进行传值。在url： ，改变hash并不会导致页面刷新，所以可以利用hash值来进行数据传递，当然数据容量是有限的。假设域名下的文件要和域名下的传递信息，首先创建自动创建一个隐藏的iframe，iframe的src 指向域名下的页面，这时的hash值可以做参数传递用。响应请求后再将通过修改的hash值来传递数据（由于两个页面

6、不在同一个域下IE、Chrome不允许修改的值，所以要借助于域名下的一个代理iframe；Firefox可以修改）。同时在上加一个定时器，隔一段时间来判断的值有没有变化，一点有变化则获取获取hash值。 代码如下： 先是下的文件文件： function startRequest（） var ifr = （none/lab/cscript/#paramdo （ifr）; function checkHash（） try var data = ? （1） : if （） （Now the data is +data）; catch（e） ; setInterval（checkHash, XX）;

7、域名下的: /模拟一个简单的参数处理操作 switch（） case #paramdo:callBack（）;break; case #paramset /do something?篇二：js跨域及解决方案 js跨域及解决方案 1.什么是跨域 我们经常会在页面上使用ajax请求访问其他服务器的数据,此时,客户端会出现跨域问题. 跨域问题是由于javascript语言安全限制中的同源策略造成的. 简单来说,同源策略是指一段脚本只能读取来自同一来源的窗口和文档的属性,这里的同一来源指的是主机名、协议和端口号的组合. 例如:2.实现原理 在HTML DOM中,Script标签是可以跨域访问服务器上的

8、数据的.因此,可以指定script的src属性为跨域的url,从而实现跨域访问. 这种访问方式是不行的.但是如下方式,却是可以的. 这里对返回的数据有个要求,即:服务器返回的数据不能是单纯的如Namezhangsan 如果返回的是这个json字符串,我们是没有办法引用这个字符串的.所以,要求返回的值,务必是var json=,或json（） 为了使程序不报错,我们务必还要建立个json函数. 3.解决方案 方案一 服务器端: protected void Page_Load（object sender, EventArgs e） string result = callback（namezha

9、ngsan,dateXX-12-03） （）; （result）; 客户端: var result = null; = function （） var script = （script = text/javascript = var head = （head）0; （script, ）; function callback（data） result = data; function b_click（） alert（）; 方案二，通过jquery来完成 通过jquery的jsonp的方式.使用此方式,对服务器端有要求. 服务器端如下: string callback = jsoncallback

10、; string result = callback + （ $.ajax（ async: false, type: GET, dataType:jsonp /jsonp的值自定义,如果使用jsoncallback,那么服务器端,要返回一个jsoncallback的值对应的对象. jsonp:jsoncallback /要传递的参数,没有传参时，也一定要写上 data: null, timeout: 5000, /返回Json类型 contentType:application/json;utf-8 /服务器段返回的对象包含name,data属性. success: function （res

11、ult） , error: function （jqXHR, textStatus, errorThrown） alert（textStatus）; ）; 实际上,在我们执行这段js时,js向服务器发出了这样一个请求: 42 而服务器也相应的返回了如下对象: name,dateXX-12-03） 此时就实现了跨域范文数据的要求。篇三：JS跨域访问解决方案总结 JS跨域访问解决方案总结 0引言： 跨域请求，顾名思义，就是一个站点中的资源去访问另外一个不同域名站点上的资源。这种情况很常见，比如说通过style标签加载外部样式表文件、通过 img 标签加载外部图片、通过 script 标签加载外部脚

12、本文件、通过 Web font 加载字体文件等等。默认情况下，脚本访问文档属性等数据采用的是同源策略（Same origin policy）。 同源策略：如果两个页面的协议、域名和端口是完全相同的，那么它们就是同源的。同源策略是为了防止从一个地址加载的文档或脚本访问或者设置从另外一个地址加载的文档的属性。如果两个页面的主域名相同，则还可以通过设置 属性将它们认为是同源的。 随着 和 SNS 的兴起，Web 应用对跨域访问的需求也越来越多，但在脚本中进行跨域请求是受安全性限制的，Web 开发人员迫切需要提供一种更安全、方便的跨域请求方式来融合（Mashup）自己的 Web 应用。这样做的一个好处

13、就是可以将请求分摊到不同的服务器，减轻单个服务器压力以提高响应速度；另外一个好处是可以将不同的业务逻辑分布到不同的服务器上以降低负载。 值得庆幸的是，跨域请求的标准已经出台，主流浏览器也已经实现了这一标准。W3C 工作组中的 Web Applications Working Group（Web 应用工作组）发布了一个 Cross-Origin Resource Sharing（跨域资源共享规范）推荐规范来解决跨域请求的问题。该规范提供了一种更安全的跨域数据交换方法。具体规范的介绍可以访问上面提供的网站地址。值得注意的是：该规范只能应用在类似XMLHttprequest 这样的 API 容器内。

14、IE8、Firefox 及其以后的版本、Chrome浏览器、Safari 4 等已经实现了 Cross-Origin Resource Sharing 规范，已经可以进行跨域请求了。 一、支持跨域访问处理浏览器 Cross-Origin Resource Sharing 的工作方式是通过添加 HTTP 头的方法来判断哪些资源允许 Web 浏览器访问该域名下的信息。然而，对于那些 HTTP 请求导致用户数据产生副作用的请求方法（特别是对于除了GET、某些 MIME 类型的 POST 之外的 HTTP方法），该规范要求浏览器对请求进行“预先验”，通过发送 HTTP 的 OPTIONS 请求头询问服

15、务器有哪些支持的方法，在征得服务器的同意后，再使用实际的 HTTP 请求方法发送实际的请求。服务器也可以通知客户端是否需要将验证信息（如 Cookie 和 HTTP Authentication 数据）随同请求一起发送。 下面我们就采用实际的例子说明 Cross-Origin Resource Sharing 是如何工作的。 1，简单请求 什么样的请求算是简单请求呢？简单请求必须满足下面2点： a，只使用 GET、POST 进行的请求，这里的POST只包括发送给服务器的数据类型（Content-Type）必须是 application/x-www-form-urlencoded、 multip

16、art/form-data 或者 text/plain中一个。 b，HTTP 请求没有设置自定义的请求头，如我们常用的 X-JSON。 先使用下面的代码进行测试： XML/HTML代码 然后，在服务器创建 的内容如下： C# 代码 点击 “开始测试” 按钮，发送的请求和返回的响应信息如下： 需要特别注意的是：在请求信息中，浏览器使用 Origin 这个 HTTP 头来标识该请求来自于 :801；在返回的响应信息中，使用 Access-Control-Allow-Origin 头来控制哪些域名的脚本可以访问该资源。如果设置 Access-Control-Allow-Origin:*，则允许所有域

17、名的脚本访问该资源。如果有多个，则只需要使用逗号分隔开即可。 注意：在服务器端，Access-Control-Allow-Origin 响应头 :801 中的端口信息不能省略。 有人可能会想：自己发送请求头会如何呢？比如 （Origin801 实践证明，自己设置 Origin 头是不行的。 是不是现在就可以采用 XMLHttpRequest 来请求任意一个网站的数据呢？还是不行的。允许哪些域名可以访问，还需要服务器来设置 Access-Control-Allow-Origin 头来进行授权，具体的代码是：（Access-Control-Allow-Origin, 这行代码就告诉浏览器，只有来自

18、 :801 源下的脚本才可以进行访问。 好了，上面我们就完成了一个简单的跨域请求，怎么样？感觉还是不错的吧。下面我们进行一个“预检”请求。 2，预检请求 预检请求首先需要向另外一个域名的资源发送一个 HTTP OPTIONS 请求头，其目的就是为了判断实际发送的请求是否是安全的。下面的2种情况需要进行预检： a，不是上面的简单请求，比如使用Content-Type 为 application/xml 或 text/xml 的 POST 请求 b，在请求中设置自定义头，比如 X-JSON、X-MENGXIANHUI 等 在 iis 里进行测试，必须在“应用程序扩展”里面配置 .aspx 扩展的动作允许 OPTIONS。 下面我们举一个预检的请求：