1. 同源策略：
协议 域名 端口 ，三者完全相同为同源。任意一个不同就是跨域。
2. 解决方案
2.1 cors:
(跨资源共享) 后台服务器提供接口时，设置允许谁访问，用什么方式访问
设置项如下：
access-control-allow-origin //允许哪些站点访问，限制访问的主机源
access-control-allow-methods //允许哪些请求方法通过
access-control-allow-methods //允许哪些请求方法通过
options类型的请求是做什么用的？
做请求预检，向服务器发起请求询问是否支持当前这次跨域请求。
什么时候发起options类型的请求？
如果是简单请求，不需要发起options预检请求，非简单请求则需要。
什么是简单请求？
- 请求类型 get post header三种之一，其他的类型视为非简单请求。
- 请求的头字段中有这几个字段 content-type accept accep-language content-length，如果超过这几个字段，比如加上了一些自定义的请求头则会被视为非简单请求。
- 请求的数据类型content-type的值text/plain application/x-www-form-urlencoded multipart/form-data这3种之外的其他类型视为非简单请求。
2.2 jsonp:(json + padding:包裹的json 请求）
- 仅能支持 get 方法的跨域
- 前端发起请求时在请求路径上告诉后台返回的函数名字，如 http://www.a.com/api/users?callback=fn 的 callback 参数，后台返回时会使用 fn 包裹 json 数据
- 在前端代码中定义 fn 函数
function fn(data) {
// 使用data数据，定义业务逻辑
}
// 前端使用script标签/ajax发起请求，请求返回`fn({a:1,b:2})`, 会执行上面定义好的fn函数，前端在函数内收到从服务器返回的数据，完成了跨域数据传输
2.3 反向代理:
1.名词解释：
正向：如果软件代理的是用户的请求，那么它就是正向代理。
反向：如果软件代理的是后台处理程序，那么它就是正向代理。
2. iframe + window.name
-
比如在www.a.com/abc页面下向www.b.com发起跨域请求，接口地址www.b.com/api/users
-
在www.a.com/abc页面1下嵌入一个iframe，iframe的地址是www.b.com/cde页面2，页面2发起接口请求，此时没有跨域的限制，当拿到接口的结果时，重置iframe的页面的src路径，把iframe的页面地址重置成www.a.com/aaa页面3，重置的同时把接口数据写入到window.name上，页面3加载完成后，读取window.name，写入到页面3的某个dom节点上。页面1监听iframe的加载事件，在事件处理函数中去读取页面3的dom元素，获取到数据
3. iframe + window.hash
3. onMessage+postMessage：ie67不支持
网友评论