跨域学习笔记

前言: 当一个资源，向与之所在服务器不同的域或端口请求另一个资源时，这个HTTP请求，我们认为是跨域的请求。出于安全考虑，浏览器会限制脚本发起的跨域HTTP请求。

那天后端让我把token放到http请求头字段里，说是为了和RN端统一，在此之前我都是放在请求体或者URL里的。于是我改请求封装部分的代码，在header里加了个

headers:{
  'access_token':config.token
}复制代码

保存+reload。。一排报错。。

Failed to load http://116.62.235.215:10081/api/order: Request header field access_token is not allowed by Access-Control-Allow-Headers in preflight response.

之前已经为跨域做了设置了，后端也给响应加了Access-Control-Allow-Origin: *，怎么还会遇到跨域的问题呢。
紧接着我发现这些请求都是 OPTIONS ？？噢，不是说简单请求(这个请求是 content-type为 application/x-www-form-urlencoded的post请求)不会触发 CORS 预检请求吗？
虽然抱着一堆疑问，我还是给后端大哥说，既然报错的是Access-Control-Allow-Headers，你在响应头加一个 Access-Control-Allow-Headers :"access_token"，我们再试试。
于是，果然好了，但是请求数直接翻了一番，所有的请求都会先发一个options，再是请求本身。。。那可不行啊，一下把所有的请求时间都翻倍了，最后我们仍然使用的旧有的方案。

但是问题并没有解决，首先
1.为什么会发一个 options 请求呢?
2.可否缓存这个 options 请求， 之后的请求就不用预检了呢？
3.加个headers还需要先向服务器报备呢？

带着这些问题 我再看了看 HTTP访问控制（CORS）
@Q1：为什么会发一个 options 请求呢?
简单请求 除了满足下图外，还需满足另一个条件，因为使用的比较少，我直接忽略了。

简单请求

需要满足上面两图的条件才归类为简单请求，我对请求的headers添加了一个自定义的头，自然不符合，所以出现了预检请求。
如果预检请求响应头返回的字段不符合真实请求的信息，便不会发起真实请求。
其实这个问题还能再问。。为什么是 options 呢？
OPTIONS用于获取目的资源所支持的通信选项。（大概是协议定的吧。。）

@Q2:可否缓存这个 options 请求， 之后的请求就不用预检了呢？
对于同一个请求是存在缓存概念的，响应头的Access-Control-Max-Age的值决定了预检请求的缓存时间。

@Q3: 加个headers还需要先向服务器报备呢？
看简单请求的条件，然后可以得出 要加的header是否标准(这里的标准似乎不同浏览器有不同..实际需再考量。)

说实话我还想知道为什么要限制。。

什么是CSRF

假如银行用于转账操作的URL ：http:www.bank.com/transfer?account=name&amount=number
那么以一个恶意攻击者在另一个网站防止如下代码: http:www.bank.com/transfer?account=anshi&amount=3000
如果有anshi在登录银行不久，且登录信息并未过期，此时她再访问该恶意网站，那么他就会损失3000元。
也就是说，这种方式能做到 欺骗用户浏览器，让其以用户的身份执行操作。
问题：
1.在另一个网站为什么能带着其他网站的身份信息？
HTTP的一个特性是..基于 cookie 和 http 认证信息发送身份凭证，也就是说不管发起请求的地址，而是看送往请求的地址，送到A站，就会携带A站的 身份信息。
一般来说，跨域请求，浏览器不会发送身份凭证...那上述例子是因为采用标签跨域的所以能携带用户信息？
2.其他的预防方式？
referer 或者 在请求参数中携带 token ；

那JSONP所谓的解决方案？

HTML自带标签的本身不受跨域的限制，自然就满足了某些需要跨域的需求。但是如果服务器对该请求的来源有限制，估计也是访问不了的。

参考资料:
讓我們來談談 CSRF
HTTP访问控制（CORS）

转载于:https://juejin.im/post/59f1882cf265da43163c4bbd