什么是同源策略？
同源策略是指，浏览器出于安全方面的考虑，只允许与本域下的接口交互。不同源的客户端脚本在没有明确授权的情况下，不能读写对方的资源。
本域包括：
- 同协议：如都是http或者https
- 同域名：如都是http://jirengu.com/a 和http://jirengu.com/b
- 同端口：如都是8080端口
什么是跨域？跨域有几种实现形式？
跨域即在不同的域（协议、域名、端口中有任意一个不同）之间发起请求，打破同源策略的限制，访问其他域的数据。
跨域的实现方式有：
- JSONP
- CORS
- 降域
- postMessage
JSONP
JSONP是JSON的一种使用方式，利用script标签可以跨域引用的特点，对跨域的数据进行请求，该方法需要后端数据配合。
使用JSONP的步骤：
- 本地创建一个数据处理函数func；
- 利用script标签，设置src路径为向服务器发送请求的端口，同时加上参数callBack = func，用于提供后端反馈数据的接口；
- 服务端在收到请求后，解析参数，计算返还数据，输出 fun(data) 字符串。
- fun(data)会放到script标签做为js执行。此时会调用fun函数，将data做为参数。
演示举例：
-
修改hosts文件，模拟跨域请求失败；
image.png
-
HTML中，通过查询城市名字，获取对应天气及图片
image.png -
js中请求为：
image.png -
浏览器访问http://a.com:8080
形成跨域，从控制台看到，响应到了浏览器之后不被允许
image.png
2.使用JSONP修改js请求
-
客户端用script向后端发送请求
image.png -
服务端响应，提供对应城市的天气和图片
image.png
image.png -
效果，访问a.com，请求127.0.0.1
image.png
CORS
CORS 全称是跨域资源共享（Cross-Origin Resource Sharing），是一种 ajax 跨域请求资源的方式，支持现代浏览器，IE支持10以上。
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。
简单请求
只要同时满足以下两大条件，就属于简单请求。
（1) 请求方法是以下三种方法之一：
HEAD
GET
POST
（2）HTTP的头信息不超出以下几种字段：
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain
浏览器请求
对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。
服务器回应
如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。
如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。
Access-Control-Allow-Origin，该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。
非简单请求
非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。
浏览器请求
非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。
浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。
服务器回应
服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。
上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示http://api.bob.com可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。
Access-Control-Allow-Methods，该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求
如果浏览器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。
说明：以上参考引用了跨域资源共享 CORS 详解 ---by 阮一峰
演示举例
客户端请求：
服务器端响应：
效果：
访问a.com，请求为127.0.0.1，实现跨域
降域
浏览器内部做了限制，只有同域名下的页面才能用JS去获取和操作iframe页面，否则只能加载，但不能用外部JS去获取和操作
通过设置document.domain的方式，将两个域名的domain设置为一个，如对于a.test.com和b.test.com，可以通过js设置document.domain = "test.com"，实现跨域
演示举例：
a.test.com:8080下的a.html内嵌了一个iframe，src为http://b.test.com:8080/b.html
正常情况下，因为a,b不同源，a不能修改内嵌的iframe中输入框的内容；
但通过降域：document.domain = 'test.com';使得a可以修改内嵌的b中的内容
postMessage
postMessage是一个web API，可以实现跨域通信。window.postMessage()被调用时，会在所有页面脚本执行完毕后，向目标窗口派发一个MessageEvent消息。语法如下：
otherWindow.postMessage(message, targetOrigin, [transfer]);
- otherwindow
其他窗口的一个引用，比如iframe的contentWindow属性、执行window.open返回的窗口对象、或者是命名过或数值索引的window.frames。 - message
将要发送到其他 window的数据。它将会被结构化克隆算法序列化。这意味着你可以不受什么限制的将数据对象安全的传送给目标窗口而无需自己序列化。 - targetOrigin
通过窗口的origin属性来指定哪些窗口能接收到消息事件，其值可以是字符串*（表示无限制）或者一个URI。在发送消息的时候，如果目标窗口的协议、主机地址或端口这三者的任意一项不匹配targetOrigin提供的值，那么消息就不会被发送；只有三者完全匹配，消息才会被发送。这个机制用来控制消息可以发送到哪些窗口；例如，当用postMessage传送密码时，这个参数就显得尤为重要，必须保证它的值与这条包含密码的信息的预期接受者的orign属性完全一致，来防止密码被恶意的第三方截获。如果你明确的知道消息应该发送到哪个窗口，那么请始终提供一个有确切值的targetOrigin，而不是*。不提供确切的目标将导致数据泄露到任何对数据感兴趣的恶意站点。 - transfer（可选）
是一串和message 同时传递的Transferable对象. 这些对象的所有权将被转移给消息的接收方，而发送一方将不再保有所有权
message 的属性有:
- data
从其他 window 中传递过来的对象 - origin
调用postMessage时消息发送方窗口的origin，这个字符串由 协议、“://“、域名、“ : 端口号”拼接而成。请注意，这个origin不能保证是该窗口的当前或未来origin，因为postMessage被调用后可能被导航到不同的位置。 - source
对发送消息的窗口对象的引用; 您可以使用此来在具有不同origin的两个窗口之间建立双向通信
安全问题：
如果不希望从其他网站接收message，请不要为message事件添加任何事件侦听器。 这是一个完全万无一失的方式来避免安全问题。
如果确实希望从其他网站接收message，请始终使用origin和source属性验证发件人的身份。 任何窗口（包括例如http://evil.example.com）都可以向任何其他窗口发送消息，并且不能保证未知发件人不会发送恶意消息。 但是，验证身份后，仍然应该始终验证接收到的消息的语法。 否则，信任只发送受信任邮件的网站中的安全漏洞可能会在网站中打开跨网站脚本漏洞。
当使用postMessage将数据发送到其他窗口时，始终指定精确的目标origin，而不是*。 恶意网站可以在您不知情的情况下更改窗口的位置，因此它可以拦截使用postMessage发送的数据。
说明：以上参考引用了MDN:window.postMessage
演示举例
a中内嵌b的iframe，同时向http://b.test.com:8080发送post消息；
并监听post消息，确认origin来自b，才使用消息内容；
b中做同样处理，向a发送postmessage，同时监听消息，确认来源为a
效果：
