标签:报错 跨域问题 var console 简单 opp dir base html
1、为什么会有跨域问题的存在?
JavaScript出于安全方面的考虑,不允许跨域调用其他页面的对象,即同源政策。
2、什么是同源?
1995年,同源政策由 Netscape 公司引入浏览器。目前,所有浏览器都实行这个政策。
最初,它的含义是指,A网页设置的 Cookie,B网页不能打开,除非这两个网页"同源"。所谓"同源"指的是"三个相同"。
(1)协议相同
(2)域名相同
(3)端口相同
具体实例 比如:http://www.example.com/zw/index.html这个网站,它的协议是http://,域名是www.example.com,端口号是80(默认端口可以省略),它的同源情况如下:
①、http://www.example.com/zwxk/manager.html 同源
②、https://www.example.com/zw/index.html 不同源(协议不同)
③、http://examle.com/zw/index.html 不同源(域名不同)
④、http://www.example.com:81zw/index.html 不同源(端口号不同)
同源政策的目的
同源策略的目的是为了保证用户信息的安全。防止恶意的网站盗取数据。
设想这样一个情景:A网站是一家银行,用户登录以后,又去浏览其他的网站B,如果网站B可以读取A网站的Cookie,会发生什么问题?
显然,如果Cookie包含隐私(比如存款总额),这些信息就会泄露,更可怕的是,Cookie往往用来保存用户的登录状态,如果用户没有退出登录,其他网站就可以冒用户,为所欲为。因为浏览器同时还规定,提交表单不受同源策略的限制。
由此可见,“同源政策”的必要性,否则Cookie可以共享,互联网就毫无安全可言了。
3、非同源限制范围
随着互联网的发展,“同源政策”越来越严格。目前,如果非同源,共有三种行为受到限制。
(1)Cookie、LocalStorage和IndexDB无法获取。
(2)DOM无法获得。
(3)AJAX请求不能发送。
虽然这些限制是必要的,但是有时很不方便,合理的用途也受到影响。下面将介绍如何规避上面三种限制。
4-1、解决跨域一:Cookie如何实现跨域
Cookie是服务器写入浏览器的一段信息,只有同源的网页才能共享,但是,两个网页一级域名相同,只是二级域名不同,浏览器允许通过设置document.domain共Cookie。
举例来说,A网站是:http:weibo.qq.com
B网站是:http:lol.qq.com
那么只需设置相同的document.domain,两个网页就可共享Cookie。
现在,A网页通过脚本设置一个Cookie。
B网页就能读到这个Cookie。
注意:这种方法只适用于Cookie和iframe窗口,LocalStorage和IndexDB无法通过这种方法规避,而要使用下文将介绍的PostMessage API。
另外,服务器也可以在设置Cookie的时候,指定Cookie的所属域名为一级域名,比如:.qq.com
这样的话,二级域名和三级域名不用做任何设置,都可以读取这个Cookie。
4-2、解决跨域问题二:如何跨域获取DOM。
如果两个网页不同源,就无法拿到对方的DOM。典型的例子是iframe窗口和window.open方法打开的窗口,它们与父窗口无法通信。
比如,父窗口运行下面的命令,如果iframe窗口不是同源将会报错。
上面命令中,父窗口想获取子窗口的DOM,应为跨源导致报错。
反之亦然,子窗口获取主窗口的DOM也会报错。
如果两个窗口一级域名相同,只是二级域名不同,那么设置4-1介绍的document.domain属性,就可规避同源政策,拿到DOM。
对于完全不相同的网站,目前有三种方法,可以解决跨域窗口的通信问题。
(1)片段识别符(fragment identifier)
(2)window.name
(3)跨文档通信API(Cross-document messaging)
4-2-1:片段识别符
片段识别符指的是,URL的#号后面的部分,比如http://qq.com/x.html#fragment的#fragment。如果只是改变片段标识符,页面将不会重新刷新、
父窗口可以把信息,写入子窗口的片段标识符。
子窗口通过监听hashchange事件得到通知
同样的,子窗口也可以改变父窗口的片段标识符。
4-2-2:window.name:
浏览器窗口有window.name属性。这个属性的最大特点是,无论是否同源,只要在同一个窗口里,前一个网页设置这个属性,后一个网页就可以读取它。
父窗口先发开一个子窗口,载入一个不同源的网页,该网页将信息写入window.name属性。
接着,子窗口跳回一个与主窗口同域的网址。
然后,主窗口就可以读取子窗口的window.name了。
优点:window.name容量很大,可以防止非常长的字符串;
缺点:必须监听子窗口window.name属性的变化,会影响网页性能。
4-2-3:跨文档消息传输window.postMessage:
上面两种方法都属于破解,HTML5为解决这个问题,引入一个全新的API:跨文档消息传输Cross Document Messaging。
下一代浏览器都将支持这个功能:Chrome 2.0+、Internet Explorer 8.0+, Firefox 3.0+, Opera 9.6+, 和 Safari 4.0+ 。
Facebook已经使用了这个功能,用postMessage支持基于web的实时消息传递。
使用方法:otherWindow.postMessage(message, targetOrigin);
otherWindow: 对接收信息页面的window的引用。可以是页面中iframe的contentWindow属性;window.open的返回值;
通过name或下标从window.frames取到的值。
message: 具体的信息内容,string类型。
targetOrigin: 接受消息的窗口的源(origin),即“协议+域名+端口”。也可以设为“*”,表示不限制域名,向所有窗口发送。
message事件的事件对象event,提供一下三个属性:
(1).event.source:发送消息的窗口
(2).event.origin:消息发向的网站
(3).event.data:消息内容
具体实例:
a.com/index.html中的代码:
b.com/index.html中的代码:
4-3、如何解决跨域LocalStorage。
通过window.postMessage,读写其他窗口的LocalStorage也成为了可能。下面是一个例子,主窗口写入iframe子窗口的LocalStorage。
上面代码中,子窗口将父窗口发送来的消息,写入自己的LocalStorage。
父窗口发送消息的代码如下.
加强版的子窗口接受消息的代码如下。
加强版的父窗口发送消息代码如下:
4-4、如何解决AJAX的跨域:
同源政策规定,AJAX请求只能发给同源的网址,否则就报错。
除了架设服务器代理(浏览器请求同源服务器,再由后者请求外部服务),有三种方法规避这个限制。
(1)JSONP
(2)WebSocket
(3)CORS
4-4-1、JSONP解决AJAX跨域问题:
JSONP是服务器与客户端跨源通信的常用方法。最大特点就是简单适用,老式浏览器全部支持,服务器改造非常小。
它的基本思想是,网页通过添加一个<script>元素,向服务器请求JSON数据,这种做法不受同源政策限制;服务器收到请求后,将数据放在一个指定名字的回调函数里传回来。
首先,网页动态插入<script>元素,由它向跨源网址发出请求。
上面代码通过动态添加<script>元素,向服务器example.com发出请求。注意,该请求的查询字符串有一个callback参数,用来指定回调函数的名字,这对于JSONP是必需的。
服务器收到这个请求以后,会将数据放在回调函数的参数位置返回。
由于<script>元素请求的脚本,直接作为代码运行。这时,只要浏览器定义了foo函数,该函数就会立即调用。作为参数的JSON数据被视为javascript对象,而不是字符串,因此避免了使用JSON.parse的步骤。
4-4-2、通过webSocket解决AJAX跨域
WebSocket是一种通信协议,使用ws://(非加密)和wss://(加密)作为协议前缀。该协议不实行同源政策,只要服务器支持,就可以通过它进行跨源通信。
下面是一个例子,浏览器发出的WebSocket请求的头信息(摘自维基百科)。
上面代码中,有一个字段是Origin,表示该请求的请求源(origin),即发自哪个域名。
正是因为有了Origin这个字段,所以WebSocket才没有实行同源政策。因为服务器可以根据这个字段,判断是否许可本次通信。如果该域名在白名单内,服务器就会做出如下回应。
4-4-3、通过CORS解决AJAX跨域
CORS是跨源资源分享(Cross-Origin Resource Sharing)的缩写。它是W3C标准,是跨源AJAX请求的根本解决方法。相比JSONP只能发GET请求,CORS允许任何类型的请求。
定义:CORS其实出现时间不短了,它在维基百科上的定义是:跨域资源共享(CORS)是一种网络浏览器的技术规范,它为Web服务器定义了一种方式,允许网页从不同的域访问其资源。而这种访问是被同源策略所禁止的。CORS系统定义了一种浏览器和服务器交互的方式来确定是否允许跨域请求。 它是一个妥协,有更大的灵活性,但比起简单地允许所有这些的要求来说更加安全。而W3C的官方文档目前还是工作草案,但是正在朝着W3C推荐的方向前进。
简言之,CORS就是为了让AJAX可以实现可控的跨域访问而生的。
以往的解决方案:
以前要实现跨域访问,可以通过JSONP、Flash或者服务器中转的方式来实现,但是现在我们有了CORS。
CORS与JSONP相比,无疑更为先进、方便和可靠。
1、 JSONP只能实现GET请求,而CORS支持所有类型的HTTP请求。
2、 使用CORS,开发者可以使用普通的XMLHttpRequest发起请求和获得数据,比起JSONP有更好的错误处理。
3、 JSONP主要被老的浏览器支持,它们往往不支持CORS,而绝大多数现代浏览器都已经支持了CORS(这部分会在后文浏览器支持部分介绍)。
详细内容:
要使用CORS,我们需要了解前端和服务器端的使用方法。
1、前端
以前我们使用Ajax,代码类似于如下的方式:
这里的“/relativeHref”是本域的相对路径。
如果我们要使用CORS,相关Ajax代码可能如下所示:
请注意,代码与之前的区别就在于相对路径换成了其他域的绝对路径,也就是你要跨域访问的接口地址。
我们还必须提供浏览器回退功能检测和支持,避免浏览器不支持的情况。
现在如果直接使用上面的脚本进行请求,会看到浏览器里控制台的报错如下:
错误显示的很明显,这是因为我们还未设置Access-Control-Allow-Origin头。
2、服务器
服务器端对于CORS的支持,主要就是通过设置Access-Control-Allow-Origin来进行的。如果浏览器检测到相应的设置,就可以允许Ajax进行跨域的访问。
HTTP 头的设置方法有很多,http://enable-cors.org/这篇文章里对各种服务器和语言的设置都有详细的介绍:
①、Apache:Apache需要使用mod_headers模块来激活HTTP头的设置,它默认是激活的。你只需要在Apache配置文件的<Directory>, <Location>, <Files>或<VirtualHost>的配置里加入以下内容即可:
②、PHP:只需要使用如下的代码设置即可。
以上的配置的含义是允许任何域发起的请求都可以获取当前服务器的数据。当然,这样有很大的危险性,恶意站点可能通过XSS攻击我们的服务器。所以我们应该尽量有针对性的对限制安全的来源,例如下面的设置使得只有http://blog.csdn.NET这个域才能跨域访问服务器的API。
③、Node的配置(基于express):
浏览器支持情况
上图为各浏览器对于CORS的支持情况(绿色为支持,数据来源:http://caniuse.com/cors),看起来相当乐观。主流浏览器都已基本提供对跨域资源共享的支持,所以,CORS才会在国外使用的如此普遍。
未来
从所有的浏览器都支持来看,CORS将成为未来跨域访问的标准解决方案。无论是自己服务器间的跨域访问,还是开放平台为第三方提供API,都将采用这种统一的解决方案,因为它简单、高效,受到所有主流浏览器的支持。它非常重要,也会让我们的网络变得更加开放。
本文部分内容转自http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
标签:报错 跨域问题 var console 简单 opp dir base html
原文地址:http://www.cnblogs.com/zuoci/p/7239891.html