cookie 的组成

cookie是浏览器中特有的一个概念，它就像浏览器的专属卡包，管理着各个网站的身份信息。

每个cookie就相当于是属于某个网站的一个卡片，它记录了下面的信息：

• key: 键，比如「身份编号」
• value: 值，比如xxx的身份编号「14563D1550F2F76D69ECBF4DD54ABC95」，这有点像卡片的条形码，当然，它可以是任何信息
• domain: 域，表达这个cookie是属于哪个网站的，比如 example.cn ,表示这个 cookie 是属于example.cn 这个网站的
• path:路径，表达这个 cookie 是属于该网站的哪个基路径的，就好比是同一家公司不同部
  门会颁发不同的出入证。比如/news, 表示这个 cookie 属于 /news 这个路径的。
• secure: 是否使用安全传输
• expire: 过期时间，表示该 cookie 在什么时候过期

当浏览器向服务器发送一个请求的时候，它会瞄一眼自己的卡包，看看哪些卡片适合附带捎给服务
器。如果一个cookie同时满足以下条件，则这个cookie会被附带到请求中：

• cookie没有过期
• cookie中的域和这次请求的域是匹配的
  （比如 cookie 中的域是 xxx.tech, 则可以匹配的请求域是 xxx.tech 、 www.xxx.tech 、blogs.xxx.tech 等等；比如cookie中的域是 www.xxx.tech, 则只能匹配 www.xxx.tech 这样的域）
• cookie是不在乎端口的，只要域匹配即可
• cookie中的path和这次请求的path是匹配的
  （比如 cookie 中的path是 /news, 则可以匹配的请求路径可以是 /news、/news/detai1、/news/a/b/c 等等；如果cookie的path是 / ,可以想象，能够匹配所有的路径）
• 验证cookie的安全传输
  • 如果cookie的secure属性是true,则请求协议必须是https,否则不会发送该 cookie
  • 如果cookie的secure属性是false,则请求协议可以是http,也可以是https

如果一个 cookie 满足了上述的所有条件，则浏览器会把它自动加入到这次请求头中。

设置 cookie

由于 cookie 是保存在浏览器端的，同时，很多证件又是服务器颁发的。

所以，cookie 的设置有两种模式：

• 服务器响应：这种模式是非常普遍的，当服务器决定给客户端颁发一个证件时，它会在响应的
  消息中包含 cookie, 浏览器会自动的把 cookie 保存到卡包中
• 客户端自行设置：这种模式少见一些，不过也有可能会发生，比如用户关闭了某个广告，并选
  择了【以后不要再弹出】，此时就可以把这种小信息直接通过浏览器的JS代码保存到 cookie
  中。后续请求服务器时，服务器会看到客户端不想要再次弹出广告的 cookie, 于是就不会再
  发送广告过来了。

服务端设置 cookie：

当这样的响应头到达客户端后，浏览器会自动的将cookie保存到卡包中，如果卡包中已经存在一模一样的卡片（其他path、domain相同），则会自动的覆盖之前的设置。

后续浏览器对服务器的请求，只要满足条件，cookie 就会被附带到请求头中传给服务器。

删除 cookie 直接让 cookie 的时间过期即可 max-age=-1。

相关配置：

1. Name-Value Pair: 每个cookie都由一个名称（name）和一个值（value）组成，这是cookie的基本组成部分 set-cookie: cookie1。

2. Expires/Max-Age:

   • Expires: 设置一个具体的日期，告诉浏览器在该日期之后cookie将不再有效。
   • Max-Age: 设置一个相对于创建时间的秒数，告诉浏览器在这段时间之后cookie将过期。

3. Domain: 指定了cookie有效的域名。只有当访问这个域名时，cookie才会被发送到服务器。

4. Path: 指定了cookie有效的路径。只有当访问这个路径时，cookie才会被发送。

5. Secure: 当这个属性被设置时，cookie只有在加密的HTTPS连接中才会被发送，增加了安全性。

6. HttpOnly: 设置这个属性可以防止JavaScript通过document.cookie访问cookie，减少跨站脚本攻击（XSS）的风险。

7. SameSite: 控制浏览器发送cookie的时机，可以设置为Strict、Lax或None，用于防止跨站请求伪造（CSRF）攻击。

   • Strict: 只有在相同的网站发起的请求中才会发送cookie。
   • Lax: 允许从一个站点发起的请求，如果该请求是顶级导航（如点击链接或提交表单），则可以发送cookie。
   • None: 允许在任何情况下发送cookie，除非设置了Secure属性。

8. Priority: 一些浏览器支持设置cookie的优先级，如Low、Medium（默认）、High，影响浏览器存储和检索cookie的顺序。

9. Host-Only: 某些浏览器允许将cookie标记为仅用于主机名，而不是子域。

10. Port: 可以指定cookie有效的端口号。如果未指定，则默认为发送cookie的端口。

11. Version: 指定了cookie的版本（如RFC 2109或RFC 6265），不同的版本有不同的属性和行为。

12. Comment: 可以包含一个注释，说明cookie的用途，但浏览器通常不会使用这个信息。

13. Discard: 如果设置，表明cookie是一个会话cookie，当用户关闭浏览器时将被删除。

14. Priority: 在某些浏览器中，可以设置cookie的优先级，影响它们在存储和检索时的顺序。

15. Samesite Attribute: 用于控制cookie在跨站请求时的行为，有助于防止CSRF攻击。

客户端设置 cookie：

document.cookie="键=值; path=?; domain=?; expire=?; max-age=?; secure";

登录中的使用

登录请求

1. 浏览器发送请求到服务器，附带账号密码
2. 服务器验证账号密码是否正确，如果不正确，响应错误，如果正确，在响应头中设置
   cookie, 附带登录认证信息（jwt）
3. 客户端收到 cookie, 浏览器自动记录下来

后续请求

1. 浏览器发送请求到服务器，希望添加一个管理员，并将 cookie 自动附带到请求中
2. 服务器先获取 cookie, 验证 cookie 中的信息是否正确，如果不正确，不予以操作，如果正
   确，完成正常的业务流程

cookie、sessionStorage 和 localStorage 的区别

cookie、sessionStorage、localStorage都是保存本地数据的方式。

其中，cookie 兼容性较好，所有浏览器均支持。浏览器针对 cookie 会有一些默认行为，比如当响应头中出现 set-cookie 字段时，浏览器会自动保存 cookie 的值；再比如，浏览器发送请求时，会附带匹配的 cookie 到请求头中。这些默认行为，使得 cookie 长期以来担任着维持登录状态的责任。与此同时，也正是因为浏览器的默认行为，给了恶意攻击者可乘之机，CSRF 攻击就是一个典型的利用 cookie 的攻击方式。虽然 cookie 不断的改进，但前端仍然需要另一种更加安全的保存数据的方式。

HTML5 新增了 sessionStorage 和 localStorage, 前者用于保存会话级别的数据，后者用于更持久的保存数据。浏览器针对它们没有任何默认行为，这样一来，就把保存数据、读取数据的工作交给了前端开发者，这就让恶意攻击者难以针对登录状态进行攻击。

cookie 的大小是有限制的，一般浏览器会限制同一个域下的 cookie 总量为4M, 而sessionStorage和localStorage则没有限制。

cookie 会与 domain、path 关联，而 sessionStorage 和 localStorage 只与 domain 关联。