禁用Cookie后Session还能用吗？

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

前言

提示：这里可以添加本文要记录的大概内容：

---

回顾一下cookie和session，举个栗子：

1. 到了医院先挂号. 挂号时候需要提供身份证, 同时得到了一张 “就诊卡”, 这个就诊卡就相当于患
   者的 “令牌”.
2. 后续去各个科室进行检查, 诊断, 开药等操作, 都不必再出示身份证了, 只要凭就诊卡即可识别
   出当前患者的身份.
3. 看完病了之后, 不想要就诊卡了, 就可以注销这个卡. 此时患者的身份和就诊卡的关联就销毁
   了. (类似于网站的注销操作)
4. 又来看病, 可以办一张新的就诊卡, 此时就得到了一个新的 “令牌”`
   而这里的令牌就是cookie，在访问每个科室的时候，就会先创建一个session，session首先会检查一下你的个人信息（就诊卡)也就是cookie。

一、Cookie和Session的关系

严格意义上来说，Cookie 和 Session 是没有任何关系的，但 Session 的实现中借助了 Cookie 机制。

通过以下 Session 执行的机制，我们就能知道 Session 是如何借助 Cookie 完成自己的执行流程的：

1.会话创建：通常情况下，当用户登录成功后，服务器会为该用户创建一个新的会话。在创建会话过程中，服务器会为该会话生成一个唯一的标识符，通常称为 Session ID。

2.Session ID 传递：服务器将生成的 Session ID 通过响应的方式发送给客户端，使用 SetCookie 命令，将用户的 Session ID 保存在 Cookie 中，通常是一个名为 JSESSIONID 的 Cookie。

3.Session 数据存储：在服务器端，Session 数据会被存储在一个能够关联 Session ID 的数据结构中（例如内存、数据库或者文件存储等）。常用的方式是将 Session ID 作为键，与对应的 Session 用户身份数据进行关联。

4.Session ID 验证与检索：当用户发送一个新的请求时，客户端会将之前存储的 Session ID 携带在请求的 Cookie 或请求头中发送给服务器。服务器会根据 Session ID 找到对应的 Session 数据，从而获得用户的状态信息。

5.Session 数据使用：服务器在获取到 Session 数据后，可以根据具体需求读取、修改或删除其中保存的状态信息。服务器可以通过 Session 来管理用户的登录状态、购物车内容、用户配置等。

6.Session 过期与销毁：Session 有一个有效期限，一般通过设置一个固定的时间，或者在一定时间内没有用户活动时会将 Session 标记为过期。当 Session 过期时，服务器会销毁对应的 Session 数据，释放内存或其他资源。

所以默认情况下，Session 是借助 Cookie 来完成身份标识的传递的，这样服务器端才能根据 Session ID 和保存的会话信息进行关联，用于找到某个具体登录的用户，所以说：默认情况下，Session 机制是依赖 Cookie 实现的。

二、禁用Cookie后Session还能用吗？

答案是：默认情况下禁用 Cookie 后，Session 是无法正常使用的。

这是因为大多数 Web 服务器都是依赖于 Cookie 来传递 Session 的会话 ID 的。客户端浏览器禁用 Cookie 时，服务器将无法把会话 ID 发送给客户端，客户端也无法在后续请求中携带会话 ID 返回给服务器，从而导致服务器无法识别用户会话。

但是，默认情况下禁用 Cookie 后，Session 就不能用了，但可以通过一些手段来解决这个问题。

三.解法

以下的两种解决方案可以绕过 Cookie 继续运行 Session：

1.URL 中携带 SessionID：可以通过 URL 重写的方式将 Session ID 添加到所有的 URL 中。服务器生成 Session ID 后，将其作为 URL 的一部分传递给客户端，客户端在后续的请求中将 Session ID 带在 URL 中。服务器端需要相应地解析 URL 来获取 Session ID，并维护用户的会话状态。

2.隐藏表单字段传递 SessionID：将 Session ID 添加到 HTML 表单的隐藏字段中。在每个表单中添加一个隐藏的字段，保存 Session ID，客户端提交表单时会将 Session ID 随表单数据一起发送到服务器，服务器通过解析表单数据中的 Session ID 来获取用户的会话状态。

这些方法虽然可以在禁用 Cookie 的情况下继续使用 Session，但需要在服务器端进行相应的代码修改和配置。但同时这些手段也带来了以下几个新问题：

1.增加了编码复杂度：需要改前端和后端代码才能继续使用 Session 机制，增加了编码复杂度。

2.增加了安全风险：这些替代方法可能会增加一些安全风险，因为 Session ID 将以明文形式出现在 URL 或表单中，很容易被第三方劫持和获取。

总结

Session 实现是依赖 Cookie 来存储会话 ID 的，所以默认情况下，如果禁用了 Cookie，Session 就不能使用了。

但是我们可以通过特殊的手段，例如在 URL 中传递 SessionID 或表单中使用隐藏字段传递 SessionID 的方式，配合服务器端代码的修改，是 Session 机制继续使用，但这样使用增加了编码的复杂度，和带来了一定的安全风险。
这篇blog就到这里了