作者: | 来源:互联网 | 2023-07-28 19:39
关于预检请求:
我们经常看到请求里偶尔会带着一个OPTIONS请求,这并不是我们人工添加的,为什么会出现呢? 原来在CORS跨域资源共享时,如果这次请求符合预检请求触发条件,就会被认为请求有一定风险,服务器它就不敢主动帮我们接受请求了,就需要由我们指定这次跨域请求哪些安全哪些不安全,所以会比普通cors请求多一步,需要提前通过OPTIONS方法的预检请求,和服务器确认我们的请求符合不符合条件:
大概看下,OPTIONS预检请求里就这几个请求头和响应头:
请求头:
- Origin:当前请求源,和响应头里的
Access-Control-Allow-Origin
对标, 是否允许当前源访问,Origin是不可修改的 - Access-Control-Request-Headers:本次真实请求的额外请求头,和响应头里的
Access-Control-Allow-Headers
对标,是否允许真实请求的请求头 - Access-Control-Request-Method:本次真实请求的额外方法,和响应头里的
Access-Control-Allow-Methods
对标,是否允许真实请求使用的请求方法
响应头
Access-Control-Allow-Credentials
:
这里的Credentials(凭证)其意包括:COOKIE ,授权标头或 TLS 客户端证书,默认CORS请求是不带COOKIEs的,这与JSONP不同,JSONP每次请求都携带COOKIEs的,当然跨域允许带COOKIEs会导致CSRF漏洞。如果非要跨域传递COOKIEs,web端需要给ajax设置withCredentials
为true,同时,服务器也必须使用Access-Control-Allow-Credentials
头响应。此响应头true意味着服务器允许COOKIEs(或其他用户凭据)包含在跨域请求中。另外,简单的GET请求是不预检的,即使请求的时候设置widthCrenditials
为true
,如果响应头不带Access-Control-Allow-Credentials
,则会导致整个响应资源被浏览器忽略。Access-Control-Allow-Headers
Access-Control-Allow-Methods
Access-Control-Allow-Origin
Access-Control-Expose-Headers
:
在CORS中,默认的,只允许客户端读取下面六个响应头(在axios响应对象的headers里能看到):Cache-Control
Content-Language
Content-Type
Expires
Last-Modified
Pragma
如果这六个以外的响应头要是想让客户端读取到,就需要设置Access-Control-Expose-Headers
这个为响应头名了,比如Access-Control-Expose-Headers: Token
Access-Control-Max-Age
:设置预检请求的有效时长,就是服务器允许的请求方法和请求头做个缓存。
关于预检请求触发特性我的一些测试:
- 两个一模一样的CORS请求,两个都会先发送OPTIONS预检请求:
- 即使设置了
Access-Control-Max-Age
,并且在时间范围内服务器修改CORS响应头,浏览器也会按照新的CORS响应头处理请求