同源策略及跨域问题
同源策略是一套浏览器安全机制,当一个源的文档和脚本,与另一个源的资源进行通信时,同源策略就会对这个通信做出不能程度的限制。
简单来说,同源策略对 同源资源 放行,对 异源资源 限制。
因此限制造成的开发问题,称之为跨域(异源)问题。
什么是源
源(origin)= 协议 + 域名 + 端口
例如 http://localhost:8080/index.html 的源为 http://localhost:8080
两个URL地址的源完全相同,则称之为同源,否则称之为异源(跨域)
跨域可能出现的场景
跨域可能出现在三中场景:
- 网络通讯的a元素的跳转、加载css、js、图片、ajax等等
- JS API window.open、window.parent、iframe.contentWindow
- 存储 webStorage、IndexedDB
对于不同的跨域场景,以及每个场景中不同的跨域方式,同源策略都有不同的限制。
网络中的跨域
当浏览器运行页面后,会发出很多请求。例如css、js、图片、ajax等等,请求页面的源称之为页面源,在该页面发出的请求称之为目标源。
当页面源和目标源一致时,则为同源请求,否则为异源请求(跨域请求)
浏览器如何限制异源请求?
浏览器处于多方面的考量,定制了非常繁琐的规则来限制各种跨域请求,但总体规则非常简单
- 对标签发出的跨域请求轻微限制
- 对ajax发出的跨域请求严格限制
解决方案
CORS
CORS(Cross-Origin Resource Sharing) 是最正统的跨域解决方案,同时也是浏览器推荐的解决方案
CORS 是一套规则,用于帮助浏览器判断是否校验通过。
CORS的基本理念是:
- 只要服务器明确表示允许,则校验通过
- 服务器明确拒绝或没有表示、则校验不通过
所以使用CORS解决跨域,必须保证服务器是自己人
CORS 将请求分为两类 简单请求 和 预检请求,对于不同种类的请求它的规则有所区别。
简单请求
简单请求:判断条件
简单来说,只要满足下列条件,就是简单请求
- 请求方式是GET POST HEAD 之一
- 头部字段满足CORS安全规范,详见W3C (浏览器默认自带的头部字段都是满足安全规范的,只要开发者不改动和新增头部,就不会打破此条规则)
- 如果有
Content-Type,必须是下列值中的一个text/plain、multipart/form-data、application/x-www-form-urlencoded
预检请求(preflight)
只要不是简单请求,均为预检请求
对简单请求的验证
对预检请求的验证
细节1 - 关于cookie
默认情况下,ajax的跨域请求并不会附带cookie,不过可以通过简单的配置就可以实现附带cookie
// xhr
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
// fetch api
fetch(url, {
credentials: "include"
})
这样一来,该跨域请求就是一个附带身份凭证的请求。当一个请求需要附带cookie时,无论它是简单请求还是预检请求,都会在请求头中添加cookie字段。而服务器响应是,需要明确告知客户端:服务器允许这样的凭据。告知的方式也非常简单,只需要在响应头中添加:Access-Control-Allow-Credentials: true即可。对于一个附带身份证的请求,若服务器没有明确告知,浏览器任然视为跨域或被拒绝。另外要特别注意的是:对于附带身份凭证的请求,服务器不得设置 Access-Control-Allow-Origin 的值为*。这就是为什么不推荐使用*的原因
细节2 - 关于跨域获取响应头
在跨域访问时,JS只能拿到一些最基本的响应头,如:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma,如果要访问其他头,则需要服务器设置本响应头。
Access-Control-Expose-Headers头让服务器把允许浏览器访问的头放入白名单,例如:
Access-Control-Expose-Headers: authorization, a, b
这样JS就能够访问指定的响应头了。
JSONP
实现原理通过浏览器对标签的限制轻微,动态的创建一个script的标签,利用标签的src属性去请求数据,服务端返回一个可执行的函数。
function jsonPRequest(url) {
return new Promise((resolve) => {
// 回调函数的名字必须要随机
const funcName = `__callback__${Math.random()
.toString(36)
.slice(2)}__${Date.now()}`;
window[funcName] = function (resp) {
resolve(resp);
script.remove();
delete window[funcName];
};
const script = document.createElement('script');
script.src = url + '?callback=' + funcName;
document.body.appendChild(script);
});
}
jsonPRequest('http://localhost:9527/jsonp').then((resp) => {
console.log('promise完成', resp);
});
虽然可以解决问题,但是JSONP有着明显的缺陷:
- 仅能使用GET请求
- 容易产生安全隐患 恶意攻击者可能利用
callback=恶意函数的方式实现XSS攻击 - 容易被非法站点恶意调用
因此,除非是某些特殊的原因,否则永远不应该使用JSONP
代理
CORS和JSONP均要求服务器是「自己人」
那如果不是呢?
那就找一个中间人(代理)
如何选择
最重要的,是要保持生产环境和开发环境一致
下面是一张决策图