HTTP和HTTPS差别之一

为什么我的应用在 localhost 登录永不失效，但部署到云端 HTTP 就“失忆”了？—— 深入解析前端会话持久化之痛

作为一名开发者，您可能遇到过这样的困惑：在本地开发环境（localhost）中，用户登录后刷新页面，甚至关闭浏览器再打开，登录状态依然保持；但将代码部署到线上服务器，并通过 HTTP 访问时，一旦刷新页面，用户就回到了登录页，仿佛应用得了“失忆症”。

这背后的罪魁祸首，往往不是您的前端代码逻辑问题，而是 HTTP Cookie 的安全属性在不同协议（HTTP vs. HTTPS）和不同环境下（localhost vs. 您的线上部署地址）的行为差异。

核心元凶：Secure 属性与 HTTP 协议的矛盾

要理解这个问题，我们首先要认识一个关键的 Cookie 属性：Secure。

1. Secure 属性的作用： 当后端在响应头中设置 Set-Cookie 时，可以为 Cookie 添加 Secure 属性（例如 Set-Cookie: sessionId=abc; Secure）。这个属性告诉浏览器：“这个 Cookie 只能通过加密的 HTTPS 连接发送。” 它的目的非常明确——防止 Cookie 在不安全的 HTTP 连接中被中间人监听和窃取，从而避免会话劫持等严重的安全漏洞。

2. 浏览器对 Secure 的严格遵守： 浏览器是严格遵守 Secure 属性的“守门员”。

   • 如果浏览器通过 HTTP 连接（非 HTTPS）接收到一个带有 Secure 属性的 Set-Cookie 响应，它会直接拒绝存储这个 Cookie。 也就是说，这个 Cookie 根本不会进入您的浏览器 Cookie 存储空间。
   • 即使您设法让一个带有 Secure 属性的 Cookie 存在于浏览器中，但如果当前页面是通过 HTTP 连接加载的，浏览器会拒绝在后续的 HTTP 请求中将这个 Cookie 包含在请求头中。

为什么 localhost 可以？

在 localhost 环境下，您的应用之所以能够保持登录态，通常是基于以下两个原因：

• 后端开发模式下的默认行为（最常见原因）： 大多数后端框架（包括 Spring Boot、Node.js Express 等）在开发环境（例如 Spring Boot 的 dev profile）下运行时，出于开发便利性考虑，会默认不为会话 Cookie 设置 Secure 属性。这意味着，即使您的前端和后端都在 http://localhost 上运行，它们之间发送的 Cookie 也没有 Secure 限制，浏览器会正常接收、存储并发送这些 Cookie。
• 浏览器对 localhost 的特殊宽松策略： 某些浏览器可能会对 localhost 或 127.0.0.1 设置的 Cookie 采取稍微宽松一些的策略。即使后端不小心在开发模式下也设置了 Secure Cookie，在 localhost 上也可能在某些情况下被允许工作。但这不如后端配置差异普遍和稳定。

为什么云端 HTTP 不行？

当您的应用被部署到云端服务器，并通过 HTTP 协议访问时（例如 http://您的域名/IP地址），问题就浮现了：

• 后端生产环境的默认行为： 与开发环境不同，当您的后端应用切换到生产环境（prod profile）运行时，出于对安全性的高度重视，后端框架通常会默认或强制为所有会话 Cookie 添加 Secure 属性。
• 前端仍然是 HTTP 连接： 如果您在浏览器中依然使用 http:// 来访问您的云端前端页面，并且前端向后端 API 发送请求（即使后端和前端在同一个域名/IP地址下，只要协议是 HTTP），那么当后端返回带有 Secure 属性的 Set-Cookie 头时，浏览器会立即识别到协议不匹配，并拒绝存储这个 Cookie。
• 结果： 您的浏览器中没有存储任何有效的会话 Cookie。当您刷新页面时，前端代码再次尝试向后端请求用户状态（例如 getLoginUserUsingGet 接口），但由于请求头中没有携带任何认证 Cookie，后端自然会认为您是“未登录”状态，并返回相应的错误码（例如您遇到的 40100）。

其他可能但次要的贡献因素：

除了 Secure 属性外，Domain 和 SameSite 属性在不同环境下的细微差异也可能间接影响 Cookie 的行为：

• Domain 属性（域名）： Cookie 的 Domain 属性指定了哪些域名可以接收和发送这个 Cookie。浏览器只会将 Domain 属性与当前请求的域名匹配的 Cookie 发送出去。localhost 比较特殊，浏览器对其 Domain 的匹配规则比较灵活。但在生产环境中，Domain 匹配非常严格。如果后端在设置 Cookie 时将 Domain 设置为与当前访问域名不匹配的值（例如，后端硬编码了 localhost 或一个错误的域名），那么即使 Cookie 被设置了，浏览器也不会在后续请求中发送它。

• SameSite 属性： 用于控制 Cookie 在跨站请求中的行为，以防止 CSRF 攻击。当 SameSite 被设置为 None（允许跨站请求携带 Cookie）时，Secure 属性是强制要求的。也就是说，SameSite=None 的 Cookie 必须通过 HTTPS 连接才能被设置和发送。如果您后端设置了 SameSite=None 但您的连接是 HTTP，那么 Cookie 也将无法工作。

如何验证和“破案”（浏览器开发者工具是您的福尔摩斯）：

要最终确认问题，您需要利用浏览器开发者工具：

1. 清除所有本地存储和 Cookie： 在两种环境（localhost 和您的云端地址）下都这样做。
2. 在 localhost 上进行登录： 登录成功后，在开发者工具的 Network (网络) 选项卡中，找到登录请求（通常是 POST 方法）。点击它，查看 Response Headers (响应标头) 中的 Set-Cookie 头部。记下所有 Cookie 的名称和属性（特别是 Domain、Path、Expires/Max-Age、HttpOnly、Secure、SameSite）。
3. 在云端 HTTP 地址上进行登录： 重复上述步骤。
4. 对比两次记录的 Cookie 属性：
   • 最重要的是：在云端 HTTP 环境下，Set-Cookie 头中是否存在 Secure 属性？ 如果存在，那么这就是问题的根源。
   • 检查 Expires/Max-Age 是否设置了足够的有效期。
   • 检查 Domain 和 SameSite 是否存在不匹配或导致发送受限的情况。

唯一的可靠解决方案：切换到 HTTPS

鉴于您前端已经修改为依赖 Cookie 进行会话管理，且后端在生产环境很可能强制 Secure 属性，那么在 “不修改后端业务逻辑” 的前提下，解决这个问题的 唯一可靠方法就是：将您的云端部署从 HTTP 升级到 HTTPS。

一旦您的前端和后端都通过 HTTPS 连接，后端设置的带有 Secure 属性的 Cookie 就能被浏览器正确接收、存储和发送。这样，您刷新页面时，浏览器会自动带上这个有效的会话 Cookie，后端就能识别您的登录状态，从而实现登录态的持久保持。

常见实现 HTTPS 的方式：

• 使用反向代理： 在您的服务器前端放置 Nginx 或 Caddy 等反向代理服务器，它们负责处理 HTTPS 连接和 SSL 证书，然后将请求转发到您后端应用的 HTTP 端口。这是最推荐和灵活的方式。
• 直接在后端应用中配置 HTTPS： 您也可以在 Spring Boot 应用本身中配置 SSL 证书和启用 HTTPS。但这通常会使后端部署稍微复杂一些。

请记住，HTTPS 不仅仅是为了解决登录态持久化问题，更是现代 Web 应用不可或缺的安全性基石。为了用户数据安全和更好的用户体验，强烈建议您尽快将线上环境升级到 HTTPS。