Tomcat Web 服务器重启后 Chrome cookie 不起作用

Question

我最近注意到，当我重新启动 Tomcat 网络服务器时，Chrome 浏览器无法再存储 cookie。即tomcat使用cookie进行http会话，浏览器无法再获取它的http会话，我们用来存储登录用户的cookie失败，用户不会保持登录状态。

这似乎是 Chrome 的一个新问题，可能来自最近的更新，我不记得以前见过它。如果我关闭 Chrome 浏览器，然后重新打开它，就可以了（直到服务器再次重新启动）。

这个问题在 Firefox 上没有发生，似乎是 Chrome 中的一个错误。

有其他人注意到这个问题，或者知道解决方案吗？

我发现了一些关于 Chrome/tomcat cookie 问题和设置建议的帖子， sessionCookiePathUsesTrailingSlash=false 在 context.xml 但这并不能解决问题。

这似乎与同时支持https和http的网站有关，并在两者之间切换（虽然它确实发生在不支持https的网站上......）

好的，我现在可以重新创建问题，步骤是。

1. 通过 https 连接到网站
2. 注销/登录
3. 通过 http 连接到网站
4. 无法再存储 Tomcat JSESSIONID cookie（奇怪的是存储了用户/密码 cookie）

这仅发生在 Chrome 上，并且仅在 Chrome 更新后在使用 http 的登录页面上添加了“不安全”标志

好的，我将它添加到我的 web.xml 中

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

这并没有解决问题，而是使问题总是通过 http 发生，即使 http 不再能够存储 JSESSIONID cookie。 我试过<secure>false</secure>，但还是遇到了老问题。 因此，它至少与此设置有关。有人有什么想法吗？

在 Chrome 上记录错误， https://bugs.chromium.org/p/chromium/issues/detail?id=698741

Answer 1

我能够用 Chrome 重现您的问题：只需从 HTTPS 区域创建 HttpSession。任何后续的 HTTP 请求都不会发送会话 cookie，并且任何通过 HTTP 对Set-Cookie:JSESSIONID= 的尝试都会被 chrome 忽略。

当用户从 HTTPS 切换到 HTTP 时，问题已局部化。即使服务器重新启动并正常工作，HTTPS 会话 cookie 也会保留。 （我使用 Tomcat6、Tomcat 9 进行了测试，并使用 apache 代理进行 SSL）

这是从 HTTPS 创建会话时 Tomcat 发送的响应标头

 Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly

这个用于 HTTP（注意 Secure 缺失）

 Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly

Chrome 会忽略第二个 set-Cookie。另一方面，Firefox 和 Edge 将 Secure cookie 替换为 not-secured。为了确定正确的行为应该是什么，我查看了RFC2109

4.3.3 Cookie 管理

如果用户代理收到一个名称为 与预先存在的 cookie 相同，并且其域和路径 属性值完全（字符串）匹配那些预先存在的 cookie，新 cookie 取代旧 cookie。

所以，很明显这是一个 chrome 错误，正如您在问题中所假设的那样：HTTP cookie 应该替换由 HTTPS 设置的那个

从 Chrome 中手动删除 cookie 或在服务器端使会话无效使其再次工作（如果在这些操作之后使用 HTTP 创建会话）

默认情况下，当从 HTTPS 请求时，JSESSIONID cookie 是使用 Secure 创建的。我想这就是 Chrome 不允许覆盖 cookie 的原因。但是，如果您尝试在web.xml 中设置<secure>false</secure>，Tomcat 会忽略它，并且Set-Cookie 标头与Secure 一起发送

<session-config>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

更改 cookie 名称、设置 sessionCookiePathUsesTrailingSlash 或删除 HttpOnly 均无效

除了在登录用户从 HTTPS 切换到 HTTP 时使服务器会话无效之外，我找不到解决此问题的方法。

最后我在 chromium 中打开了一个 bug：https://bugs.chromium.org/p/chromium/issues/detail?id=698839

---

更新 该问题最终被标记为 Won't Fix，因为这是一个有意的更改。见https://www.chromestatus.com/feature/4506322921848832

严格的安全 Cookies

这增加了对标有“安全”属性的 cookie 的限制。目前，不安全（例如 HTTP）的来源无法访问安全 cookie。但是，不安全的来源仍然可以添加安全 cookie、删除它们或间接驱逐它们。此功能会修改 cookie jar，以便不安全的来源无法以任何方式接触安全 cookie。这确实为 cookie 驱逐留出了余地，这仍然可能导致安全 cookie 被删除，但只有在所有非安全 cookie 都被驱逐之后。

Answer 2

我记得看过几次，据我所知，这是关于此事的唯一建议，正如你提到的：

一个可能的解决方案可能是在context.xml 中添加sessionCookiePathUsesTrailingSlash=false，看看效果如何。

来自here的一些信息

讨论here (same solution)

希望我没有混淆这些问题，这对你有帮助，如果我需要编辑/如果工作/如果我应该删除，请在评论中告诉我，谢谢！

Answer 3

有一个draft document 反对修改来自非安全来源的“安全”cookie（由 Google 提交）。它指定了修改HTTP State Management Mechanism 文档的建议。

文件摘要：

本文档更新了 RFC6265，删除了非
使用“安全”标志设置 cookie 并覆盖
设置了“安全”标志的 cookie。此弃用改进了
HTTP 和 HTTPS 源之间的隔离，并降低风险
恶意干扰。

Chrome already implemented this feature in v 52 和几天前的 implemented in Mozilla 也是相同的功能。

要解决这个问题，我认为你应该只通过 https 连接到网站。

Answer 4

我认为不好的方法是在context.xml中设置sessionCookieName = "JSESSIONIDForHttp"

让浏览器的cookie知道：

1. 如果安全https 条件使用默认"JSESSIONID"。

2. 如果不安全 http 条件使用 "JSESSIONIDForHttp"。