所谓同源(即指在同一个域)就是两个页面具有相同的协议(protocol),主机(host)端口号(port)
同源策略是浏览器的一个安全功能,不同源的客户端脚本在没有明确授权的情况下,不能读写对方资源。 同源策略是浏览器安全的基石
同源策略会阻止一个域的 javascript 脚本和另外一个域的内容进行交互。例如办公内外网环境,当我们访问外网一个恶意网站的时候,恶意网站就会利用我们的主机向内网的 url 发送 ajax 请求,破坏或盗取数据
1|0浏览器的非同源限制以及3种解决思路
非同源限制
- 无法读取非同源网页的 Cookie、LocalStorage 和 IndexedDB
- 无法接触非同源网页的 DOM
- 无法向非同源地址发送 AJAX 请求,即 XHR 请求
跨域的解决思路 1 —— 避免非同源限制
- 让浏览器不做限制,指定参数,让浏览器不做校验,但该方法不太合理,因为它需要每个人都去做改动
- 不要发出 XHR 请求,这样就算是跨域,浏览器也不会有非同源限制,解决方案是 JSONP,通过动态创建一个 script,通过 script 发出请求
跨域的解决思路 2 —— 跨源资源共享方案
- 根据 W3C 的跨源资源共享方案,在被调用方修改代码,加上字段,告诉浏览器该网站支持跨域
跨域的解决思路 3 —— 隐藏跨域
- 使用 Nginx 反向代理,在 a 域名里面的的请求地址使用反向代理指向 b 域名,让浏览器以为一直在访问 a 网站,不触发跨域限制
2|0JSONP
- 普通请求值 XHR,希望得到服务端返回的 content-type 一般是 json
- JSONP 发出的是 script 请求,希望得到的返回是 js 脚本
Content-Type 是指 http/https 发送信息至服务端时的内容编码类型,在 HTTP 协议消息头中,使用 Content-Type 来表示请求和响应中的媒体类型信息。它用来告诉服务端如何处理请求的数据,以及告诉客户端(一般是浏览器)如何解析响应的数据,比如显示图片,解析并展示 html 等等。
并不是请求或响应独有的参数
2|1JSONP 原理
以 JQuery 为例,发送 ajax 请求的时候,设置dataType:"jsonp"
,将使用 JSONP 方式调用函数,函数的 url 变为myurl?callback=e5bbttt
的形式,e5bbttt 就是一个临时方法名,后端会根据callback
的值返回一个 js 脚本,如
<script>
e5bbttt({"a":"aaa","b":"bbb"});
</script>
JQuery 会提前根据 ajax 中 success 的内容生成一个临时函数,名字就是 xxx
$.ajax({
// 其他省略
dataType:"jsonp",
success:function(data){
console.log(data.a);
console.log(data.b);
},
jsonp:"e5bbttt"
})
// JQuery 生成的临时函数
function e5bbttt(data){
ajaxObject.success(data);
}
服务端返回给客户端的e5bbttt({"a":"aaa","b":"bbb"});
,相当于调用立即(?)调用了 JQuery 生成的e5bbttt
函数,用完这个函数就销毁了(?)
JSONP 也算是一个约定俗成的“协议”,callback 是约定俗成的作为定义临时函数名的参数。如果想自定义这个参数名,需要在 ajax 中用 jsonp 属性定义。
2|2JSONP 的弊端
- 需要服务器改动代码
- 只支持 GET 请求
- 发送的不是 xhr 请求
- 不安全
3|0后端解决跨域
跟用户数据有关的就是动态请求,没有数据的是静态请求,比如 css js,so,HTTP 服务器(Apache、Nginx 等)至少做了两个作用
- HTTP 服务器,处理静态请求
- 反向代理,负载均衡
在服务器端解决跨域有2种解决思路
- 在被调用后端应用解决:在响应头增加指定字段,告诉浏览器允许调用。这种解决方案的请求是直接从浏览器发送给后端服务器,在浏览器上会看到 b.com 的 url
- 在前端服务器解决:这是隐藏跨域的解决方案。这种跨域请求不是直接从浏览器发送的,而是从中间的 http 服务器(前端应用所在服务器)转发过去的,在浏览器中看到的还是 a.com 的 url,所以不会认为是跨域。但是该到 b.com 的请求还是会到 b.com