Cookie

服务器在 HTTP 响应中， 通过Set-Cookie命令浏览器存储一个cookie(通常不大于4KB)并为其配置属性

• 注意，多个同名cookie只要其他属性有任何一个不同，就不会相互覆盖，而是都存起来。

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco;Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Set-Cookie: tasty_cookie=strawberry; Secure; path=/blog

[page content]

此后浏览器每次对Cookie的Domain对应的域发起HTTP请求时，自动把这个Cookie携带到请求的Header中

• 和请求地址有关，当前网页URL无关。如当前网页为A，对B发起了请求，则带上的为B的cookies，和A无关

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

cookie属性

• Domain
  域名，下次浏览器访问该域名时会带上cookie
• Path
  限制具体路径，如果路径不能匹配时，即使Domain符合条件也不发送Cookie
• Name、Value
  实际有意义的数据，浏览器请求符合条件的地址时会带上该数据
• Expires、Max-Age
  过期日期和最大失效时间，同时设置时Max-Age生效。若均为设置则为Session Cookie，本次浏览器关闭时即清空
• Secure
  为 true 时，cookie 仅在 HTTPS 中才有效
• HttpOnly
  为 true 时，通过程序（JS 脚本document.cookie、applet 等）将无法读取到COOKIE 信息，防止 XSS 攻击产生
• Singed
  表示是否签名cookie, 设为true 会对这个 cookie 签名，这样就需要用 res.signedCookies 而不是 res.cookies 访问它。被篡改的签名 cookie 会被服务器拒绝，并且 cookie 值会重置为它的原始值
• SameSite
  用来限制第三方 Cookie，从而防止CSRF攻击。
  • Strict
    只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
    由于从当前网页打开一个新页面也算一种请求，会导致打开其他域下的网页时，页面请求也不带cookie，此时如果是后端渲染就无法读取到信息了
  • Lax (默认值)
    允许导航到目标网址的 Get 请求获取cookie
  • None
    不做任何限制
    为保证安全，只有在cookie同时具有Secure属性时才能设置为None

document.cookie

document.cookie属性用于读写当前网页的 Cookie。

• 读取时仅可获得无HTTPOnly的cookie
• 写入时一次只能写入一个，需写成key=value形式，且必须对分号、逗号和空格进行encodeURIComponent转义（它们都不允许作为 Cookie 的值）

document.cookie = 'fontSize=14; '
  + 'expires=' + someDate.toGMTString() + '; '
  + 'path=/subdirectory; '
  + 'domain=*.example.com';

• 删除一个现存 Cookie 的唯一方法，是设置它的expires属性为一个过去的日期

Session

Session是一种服务端的机制，服务器使用哈希表结构（key-value）来保存信息。通过客户端请求传入的key进行匹配，以识别客户端的身份。
Session通常借助Cookie或Storage将key存在浏览器端，通过redis将key-value对照关系存在服务器端

一个常见的校验方式

1. 生成3个COOKIE,分别使用用户名，登录时间，用户名+登录时间DES加密后的密文
2. 使用COOKIE与SESSION进行比对验证
3. 使用JWT生成TOKEN,解密出被加密的部分进行验证。

JWT

将用户信息加密后直接传给前端作为token，前端每次请求带上该token，服务器端解密后直接获得用户信息。比起普通的Session认证，不依赖cookie和session，不受CSRF攻击，信息不用存储在服务器端（节省开销且利于分布式系统）。