跨域
跨域问题的本质：
请求和相应都是正常的，拿到响应结果也是正常的，浏览器阻止最终的js 代码获取 || 操作跨域请求的资源。它是浏览器的安全策略，防止通过自定义请求头或者cookie注入有毒的东西。
解决方法：
- script方式
浏览器只对fetch和xhr进行限制。所有的script标签，img标签，link标签都没有跨域问题。
- proxy方式
客户端代理到同源服务器上发送请求。但是每个前端项目配置一个同源服务器十分没有必要。
- cors
服务器端设置白名单，配置可以进行访问的源，就可以进行简单请求。如果非简单请求，浏览器会再发送一个OPTIONS请求进行预检。对非简单请求方式，需要规定可以访问的方式和请求头。另外，cors跨域请求时，很难对cookie操作，除非对相关字段进行配置。
常用的配置信息：
- Access-Control-Allow-Origin: 从请求头中获取请求跨域的主机名，被请求的服务器设置字段：Access-Control-Allow-Origin，相当于服务器设置白名单，浏览器就不会进行拦截。
- Access-Control-Allow-Methods: 请求方式默认只允许简单请求方法get，post，其余请求方式浏览器会认为是需要预检的请求。因此浏览器会给服务器再发送一个mothods为options的请求，进行预检。
- Access-Control-Allow-Headers: 允许客户端设置什么请求头: 自定义请求头;非自定义但不是简单请求头。其中content-type的值默认不能为application/json，格式太灵活，容易向服务器写入乱七八糟的数据
- Access-Control-Allow-Credentials: 设置了之后set-cookie可以向cookie里面存东西。
- Access-Control-Expose-Headers: 允许暴露给客户端的响应头，让浏览器访问这些响应头。否则登录拿不到authorization和set-cookie响应头。
登录方式
Cookie
浏览器自动设置，set-cookie将用户信息记录到cookie，请求时候带到请求头。明文存储，没有进行任何处理。
Jwt
手动发和带。jwt的密钥只存在服务器端，下次发送时会进行验证。
sessionID + cookie
-
cookie缺点：
- 是字符串，不能存对象。会转格式。
- 储存内容有限。
- 想改就能改。
-
session将内容存储在服务器端，而仅仅给客户端传入相应的sessionID存储在cookie中。缺点是后端查询会非常繁忙，任务量大。
采用Cors方式进行跨域的话，cookie会难以操作，session对服务器端要求大，查询多。因此当采用Cors跨域，采用jwt进行登录鉴权。
