摘要：例外当涉及到同源策略时，有两个主要的例外授信范围两个相互之间高度互信的域名，如公司域名，不遵守同源策略的限制。端口未将端口号加入到同源策略的组成部分之中，因此和属于同源并且不受任何限制。
原文链接：http://www.devsai.com/2016/11/24/talk-CORS/
同源策略（same origin policy）1995年，同源政策由 Netscape 公司引入浏览器。为了防止某些文档或脚本加载别的域下的未知内容，防止造成泄露隐私，破坏系统等行为发生。
同源策略做了两种限制:
不能通过ajax的方法或其他脚本中的请求去访问不同源中的文档。
浏览器中不同域的框架之间是不能进行js的交互操作的。
现在所有的可支持javascript的浏览器都会使用这个策略。
怎么算同源URL的三部分完全相同时我们就可以称其为同源,这三部分是: 协议，域名（主机名）和端口都相同。
IE 例外当涉及到同源策略时，Internet Explorer有两个主要的例外
授信范围（Trust Zones）：两个相互之间高度互信的域名，如公司域名（corporate domains），不遵守同源策略的限制。 端口：IE未将端口号加入到同源策略的组成部分之中，因此 http://company.com:81/index.html 和http://company.com/index.html 属于同源并且不受任何限制。跨域的几种解决方法
虽然同源策略很有必要，但有很多时候我们还是需要去请求其他域的数据，如：调用不同业务的数据，而不同业务已子域区分；又或者是第三方公用的数据接口等等
由于各种原因，我们需要通过各种方式来请求到不同域下的资源。
jsonpjsonp是通过可以发出跨域请求的script标签,使javascript能够获得跨域请求的数据，并调用数据。
先看个例子：
文件index.js :
alert(123);
页面index.html:
... ...
当加载页面index.html后，出123内容的弹窗。通过查看index.js的响应体，会发现响应内容就是alert(123)。
所以，可以这么思考，只要是通过script标签请求到的内容就会被当做js代码执行。
是否可以在script中的地址src不请求js文件，而是请求服务端的接口（即使不在同源下的），那么返回的内容就能获得到，并且会当成js代码来执行。（一般的script标签都会去请求js代码文件）
再来看下正常的服务端获取数据接口。
比如:有这么个接口/getUserInfo/001,通过ajax请求获得此接口数据{"data" : {"name" : "devsai",like:"everything"}}。
得到数据后在ajax中调用showUserInfo(data)来渲染页面，data就是接口数据。
如果现在用script标签来请求数据,那么同样可以获得数据，执行返回到的内容，因是json格式的数据，并不会报错，但也并没有卵用。获得接口的数据肯定是想做些什么的。
再想想，正常ajax请求后的js执行内容showUserInfo(data),拿到数据后，调用了showUserInfo函数。
那么，用script标签来请求数据时，返回的内容直接是showUserInfo(data)不就行了，但服务端又不知道我们到底要执行哪个函数，即使事先约定了，但后面因某些事要改，那还得告诉服务端，太麻烦了。
如果知道要执行什么函数就好了。
当然，这是可以的，改造下接口，以参数的形式把函数名传给服务端。
Response返回的内容同样需要改造
Response:
showUserInfo({"data" : {"name" : "devsai",like:"everything"}})
这样，通过jsonp，去跨域请求接口数据就完成了。
需要注意的是函数名需要挂在window下面，要不然会报函数名未定义。
例如在demo.devsai.com/index.html页面里执行如下内容：
document.domain = "devsai.com";
执行该语句后，可以成功通过devsai.com/index.html的同源检测, 实现数据的通讯，
当然document.domain不能随意设置，只能设置成当前域，或设置成当前域的顶域。
document.domain常常被用于同站但不同域的情况，例如：www.devsai.com，下嵌入了iframe广告页面ad.devsai.com,想要实现两页面的通讯，就需要对两个页面都设置document.domain="devsai.com"。
window.namewindow对象有个name属性，该属性有个特征：即在一个窗口(window)的生命周期内,窗口载入的所有的页面都是共享一个window.name的，每个页面对window.name都有读写的权限，window.name是持久存在一个窗口载入过的所有页面中的，并不会因新页面的载入而进行重置。
name只能是字符串。
页面a.html中:
页面b.html:
再来看看如何让a.html页面获取数据
用data.html作为请求数据地址:
Data
a.html：
... ...
当访问http://127.0.0.1:8080/static/index.html,便能获得来自不同域下data.html中的数据。
也可以做的更完善些，动态的生成iframe请求数据，用完即毁。
....
// 传入请求数据接口地址和回调函数
function requestData(url,successCB){
var body = document.getElementsByTagName("body")[0];
var iframe = document.createElement("iframe");
iframe.setAttribute("id", "getDataByWindowName");
iframe.setAttribute("width", "0");
iframe.setAttribute("height", "0");
iframe.setAttribute("border", "0");
iframe.setAttribute("style", "width: 0; height: 0; border: none;");
iframe.setAttribute("src", url);
body.appendChild(iframe);
setTimeout(function(){//防止iframe.src在没加载前就被替换
iframe.onload = function(){
var data = iframe.contentWindow.name;
if(data){
data = JSON.parse(data);//转成 JSON
successCB && successCB(data);
}
iframe.parentNode.removeChild(iframe);
}
iframe.src = "about:blank";
}, 100);
}
//requestData("http://localhost:8080/static/data.html",showUserInfo);
...
这就是使用window.name来进行跨域。
window.postMessagewindow.postMessage方法是html5的新特性之一，
可以使用它来向其它的window对象发送消息，不管这个window对象是属于同源或不同源。
通过window.postMessage允许浏览器windows, tabs, and iFrames之间跨域通讯。
之前写过一篇关于window.postMessage的，做了详细的说明+演示页面+演示代码,去看看
服务端地址映射例如一个网站上有各种不同的业务，不同的业务有其对应的子域。
如：ad.devsai.com;upload.devsai.com;live.devsai.com，分别对应广告业务，上传业务，直播业务。
想在www.devsai.com中做交互，或获得数据，便会受跨域影响。
造成跨域的原因是因为请求数据的源不同，那只要请求的源一样，便没有跨域问题了。
这也是可以办到的，只需要web服务做下代理，或称之为地址映射。
拿Nginx举例，需要在web服务上做如下配置：
...
lcaotion /ad {
proxy_pass http://ad.devsai.com
}
location /upload {
proxy_pass http://upload.devsai.com
}
location /live {
proxy_pass http://live.devsai.com
}
...
然后就可以在以www.devsai.com/ad/的方式去调用广告业务。
CORS跨域资源共享当一个发起的请求地址与发起该请求本身所在的地址不在同源下时，称该请求发起了一个跨域的HTTP请求。
有些的跨域请求是被允许的,
跨域下的 window.onerror报错信息
通过script标签上添加crossdomain属性,并在服务上配置响应头。
在去看onerror中的报错信息就和同源下的报错信息一样了。
4 Web字体 (CSS 中通过 @font-face 使用跨站字体资源)，使用非同源地址，同样会报错。
还需要注意的一点是，跨域请求并非是浏览器限制了请求，而是浏览器拦截了返回结果。不管是否跨域，请求都会发送到服务端。
但也有特例，有些浏览器不允许从HTTPS的域跨域访问HTTP，比如Chrome和Firefox，这些浏览器在请求还未发出的时候就会拦截请求。
解决这类跨域问题的方法就是*CORS*，对于简单的请求来说，前端这边都不需要做任何的编码就能实现跨域请求，
只需要服务端配置响应头"Access-Control-Allow-Origin:*"。
CORS是一个W3C标准,全称“跨域资源共享”（Cross-origin resource sharing）
跨源资源共享标准通过新增一系列 HTTP 头，让服务器能声明哪些来源可以通过浏览器访问该服务器上的资源。
CORS服务端设置(Set Response Header)Access-Control-Allow-Origin
根据Reuqest请求头中的Origin来判断该请求的资源是否可以被共享。
如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（该字段的值为服务端设置Access-Control-Allow-Origin的值）便知出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。此时HTTP的返回码为200，所以 这种错误无法通过状态码识别。
Access-Control-Allow-Credentials
指定是否允许请求带上cookies，HTTP authentication，client-side SSL certificates等消息。
如需要带上这些信息，Access-Control-Allow-Credentials:true并需要在XmlHpptRequest中设置xhr.withCredentials=true。
需注意的是，当设置了the credentials flag为true,那么Access-Control-Allow-Origin就不能使用"*"
Access-Control-Max-Age
可选字段，指定了一个预请求将缓存多久，在缓存失效前将不会再发送预请求。
Access-Control-Allow-Methods
作为预请求Response的一部分，指定了真实请求可以使用的请求方式。
Access-Control-Allow-Headers
作为预请求Response的一部分，指定了真实请求可以使用的请求头名称(header field names)。
CORS两种请求方式CORS的有两种请求方式： 简单请求(Simple Request) 和 预请求(Prefilght Request)
简单请求(Simple Request)只要同时满足以下三大条件，就属于简单请求。
a) 请求方式是以下几种方式之一
* GET * POST * HEAD
b) content-type必须是以下几种之一
* application/x-www-form-urlencoded * multipart/form-data * text/plain
c) 不会使用自定义请求头（类似于 X-Modified 这种）。
预请求(Prefilght Request)如果不满足简单请求的三大条件，会在发送正真的请求前，发送个请求方式为"OPTIONS"的请求，去服务端做检测，
1） 请求方式不是GET,POST,HEAD
那么需要在响应HEAD配置允许的请求方式，例如：Access-Control-Allow-Methods:PUT,DELETE
2) 使用自定义请求头,如x-devsai ，那么需要在服务端相应配置允许的自定义请求头:Access-Control-Request-Headers: x-devsai
一旦检测不通过，浏览器就会提示相应的报错，并不会发生真实的请求。
CORS兼容性从上图可只IE11,以下的就不支持CORS了。但实际上再IE8,IE9,IE10中，可以用XDomainRequest对象代替XmlHttpReuqest，发送跨域请求。
var xdr = new XDomainRequest();
xdr.open("get", "http://www.devsai.com/xdr");
xdr.send();
结语
最后，总结下各种跨域方案的特点，还记得本文开始说的，同源策略的两种限制吗？
不能通过__ajax的方法__或__其他脚本中的请求__去访问不同源中的文档。
浏览器中不同域的框架之间是不能进行js的交互操作的。
把第1种标记为__TYPE_1__,第二种标记为__TYPE_2__，对上述的几种解决跨域的方法分下类。
window.name 需要注意name只能是字符串
解决的限制 ：__TYPE_1__,__TYPE_2__
缺点： 接口返回的内容必须都是html里嵌入script脚本。
document.domain 通过修改domain跨子域
解决的限制 ：__TYPE_2__
缺点： 仅支持同个域下的子域跨域，跨域能力有限
window.postMessage 用于iframe、window、tabs之间的跨域通讯
解决的限制 ：__TYPE_2__
缺点： 兼容问题，IE10以下受限，IE8以下无效
jsonp 是之前最常用的解决跨域请求的方法。
解决的限制 ：__TYPE_1__
缺点： 不能用于POST请求
服务端地址映射 前端不需要管，并能解决跨域请求问题的一种方法。
解决的限制 ：__TYPE_1__
缺点： 非要说缺点，那就是要说服服务端同学,而且一般场子铺大了的公司只用同源，不太可能。
CORS 感觉目前比较常用的解决跨域请求的方法。
解决的限制 ：__TYPE_1__
缺点: 也是兼容性问题
真正开发过程中，需针对不同情况，使用不同的解决之法。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/81011.html
摘要：为了防止某些文档或脚本加载别的域下的未知内容，防止造成泄露隐私，破坏系统等行为发生。模式构建函数响应式前端架构过程中学到的经验模式的不同之处在于，它主要专注于恰当地实现应用程序状态突变。严重情况下，会造成恶意的流量劫持等问题。 今天是编辑周刊的日子。所以文章很多和周刊一样。微信不能发链接，点了也木有用，所以请记得阅读原文~ 发个动图娱乐下： 使用 SVG 动画制作游戏 使用 GASP ...
摘要：可以说同源策略在安全中扮演着及其重要的角色。我把这个领域的东西写成了一个系列，以后还会继续完善下去安全一同源策略与跨域安全二攻击安全三攻击 之所以要将同源策略与跨域写在一起，是因为存在浏览器的同源策略，才会存在跨域问题 何为同源策略 同源策略是浏览器实现的一种安全策略，它限制了不同源之间的文档和脚本交互的权限。只有同一个源的脚本才会具有操作dom、读写cookie、session 、a...
摘要：扯了这么多，自然不是为了吹水，而是要为了引出前端开发的一个重要的知识点同源策略什么是同源策略出于保护用户信息安全的目的，现在的浏览器都会实施同源策略这个政策，所谓同源策略指的是不同源的客户端脚本在没有明确授权情况下，不允许读写对方的资源。 导语你家的小孩带了他的朋友来你们的家里玩，你家的小孩如果要在自家屋里拿玩具玩、拿东西吃你自然是不会阻止，但是如果你家小孩的朋友人品不行，乱拿东西吃、...
摘要：扯了这么多，自然不是为了吹水，而是要为了引出前端开发的一个重要的知识点同源策略什么是同源策略出于保护用户信息安全的目的，现在的浏览器都会实施同源策略这个政策，所谓同源策略指的是不同源的客户端脚本在没有明确授权情况下，不允许读写对方的资源。 导语你家的小孩带了他的朋友来你们的家里玩，你家的小孩如果要在自家屋里拿玩具玩、拿东西吃你自然是不会阻止，但是如果你家小孩的朋友人品不行，乱拿东西吃、...
摘要：由于浏览器的同源策略导致无法直接通过拿到后台数据。目前，如果非同源，共有三种行为受到限制。此处应有掌声参考关于跨域资源共享和浏览器的同源策略限制的具体讲解。 工作中，经常会遇到需要跨域请求数据的情况。由于浏览器的同源策略,导致无法直接通过ajax拿到后台数据。解决这个问题的方式之一就是JSONP。还有一种方式更高效简单——跨域资源共享(Cross-origin Resource Sha...
阅读 3137·2021-09-30 09:47
阅读 1965·2021-09-22 16:04
阅读 2240·2021-09-22 15:44
阅读 2518·2021-08-25 09:38
阅读 524·2019-08-26 13:23
阅读 1203·2019-08-26 12:20
阅读 2793·2019-08-26 11:59
阅读 1043·2019-08-23 18:40
