认证授权1 — cookie,session

给自己挖个坑，写个认证授权的系列文档，这是第一篇

• cookie 结合 session 认证

• JWT 认证

• 类似微信扫码认证

• Oauth2 认证

• 单点登录

• LDAP 认证

如果对  cookie 已经很熟悉了，可以跳过，这篇主要是为后面的做铺垫

what is cookie，网上已经说烂了，还不知道可以看MDN

 概要

• cookie 组成

• cookie 产生整个交互过程

• cookie seesion 存在的问题

• demo

cookie 组成

虽然cookie 属性说烂了，列还是得列一下，主要关注 Domain , HttpOnly , SameSite

Name, Value
Name 和 Value 是必须的 Session 里的 SessionId 就是 Name 设置的

Domain

默认是当前域名 假设 访问的是a.hucheng.com,那么前端cookie的domain只能设置a.hucheng.com和其父域名hucheng.com，如果设置成同级域名如b.hucheng.com或者子域名a.aa.hucheng.com 那么cookie设置将无效。

当cookie设置父域名hucheng.com的时候 ,2个子域名(a.hucheng.com,b.hucheng.com)就可以获取到cookie的信息,通过cookie来传递信息

划重点 Domain 的这种属性 可以用来 子域名之间的通信**，大部分二级域名之间跳转都是使用这个属性

• Path

  设置路径cookie 生效路径

• Max-Age // 过期时间
  默认是毫秒,超过这个时间，浏览器自动删除，其实还有个Expires,Expires 是 Http1.0的，基本废弃了

• Size 

   默认 8k, 只读  

• HttpOnly  
  httpOnly,设置了这个就不能通过js 里的 document.cookie 获取了，默认是false,这个特性，也用的很多，一般我们敏感的信息都设成tre，比方 seesionId，token，非敏感设置成 false，比方记录来源

• SameSite
  这个是 Chrome 提出来的 跨域共享 cookie

• Secure  
  只有在 https里使用,传输过程会加密

cookie 产生整个交互过程

1. 使用浏览器访问服务端页面；

2. 服务端收到该客户端第一次请求后，会创建一个 session ，生产一个唯一 sessionId ；

3. 同时在响应请求中设置 cookie ，属性名为jessionid；

4. 客户端收到后会保存 jessionid ，再次请求时，会在 header 中设置，服务端可从请求头中获取；

5. 服务端验证获取的 sessionId 是否存在，即可验证是否是同一用户；

当浏览器禁用 cookie 后，基于 cookie 的 session 将不能正常工作，每次都将创建一个新的 session ，可通过url重写传递 sessionid。

cookie seesion 存在的问题

在网民不多，喷子还很少的年代，cookie seesion 是够用的，但是负载大了以后，比方微博这种，一个系统保存上亿的 seessionId，也是够够的，那是不是可以搞个负载均衡 ，把 sessionId 都存到 Redis 缓存，所有的机器都来访问这个地方的数据， 这样一来，就不用复制了， 但是增加了单点失败的可能性， 要是那个负责 session 的机器挂了，  所有人都得重新登录一遍， 估计得被人骂死。

怎么办？ 有没有啥办法，我不存这些用户 sessionId,让浏览器自己管理起来么，JWT 小老弟，要出场了,下回讲 JWT