iOS 偶尔会发送旧的 cookie

Question

我有一个定期轮换身份验证 token cookie 值的应用程序。

每次服务器轮换 token 时，它不会将其标记为“好”，直到它看到客户端拥有 token (因为客户端将其包含在资源的请求 header 中)。

我只有在 iOS (10.3) 上有一个非常特殊的情况，当网络条件发生变化时(例如:下地铁)，它偶尔会发送一个非常旧的 cookie。当这种情况发生时，它会“忘记”最近的 cookie 值并“开始生活在过去”并发送旧值。

^{** 安全说明:IP 地址是在纽约市公开分配的 t-mobile， token 早已从我们的数据库中删除}

• 这是一个已知问题吗？
• 是否有任何在 iOS 上更可靠的 cookie 处理变通办法？ localstorage 并不理想，因为这些 cookie 仅为 http。

为了澄清......这是流程:

1. 客户端 (iOS Safari) 有一个名为 _t 的 cookie，其值为 old
2. 客户端(iOS Safari)向服务器发出请求
3. 我们发出 Set-Cookie 并将 _t cookie 设置为新值 new(仅限 http，安全 cookie)
4. 客户端使用新的 cookie 值 new 发出另一个请求。我们标记 cookie 值是好的并且客户端有它。
5. 时间流逝
6. 客户端使用值为 old 的 _t cookie 发出请求

Answer 1

这是我对发生的事情的理论:

从cookie的生命周期来看，每当用户身份验证状态发生变化(登录用户->注销用户||注销用户->登录用户)时，旧cookie将失效并被新cookie取代。

但为什么这种情况发生在地铁而不是其他地方？
1. 如今，大多数地铁都提供免费的不安全 WiFi，以补充地下糟糕的无线网络连接。
2. 在 10.3 中有一些关于网络连接问题的报告，以及 this one特别有趣，因为问题是location dependent。
3. 我认为上述 (1) 和 (2) 的组合导致应用程序重新向服务器进行身份验证。也许你可以提取日志来检查是否确实如此？

可能的解决方法？

也许没有。
我们无法阻止iPhone 用户进行iOS 升级。大多数人已经这样做了。
此外，在重新验证后不更改 cookie 的安全影响更糟。

根据截至 2017 年 5 月 31 日的评论更新:

鉴于评论中的详细信息。我们可以有更好的解释。

在cookie生命周期中，当用户注销时，server-side-invalidation应该发生。

工作流程:
1. 当用户注销时，authenticated sessionID从浏览器中删除。
2. 但这还不够。服务器也需要使那个sessionID。否则可能会产生安全影响。
3.在您的情况下，服务器可能没有失效。因此，它仍然需要一个 SessionID，它已被从浏览器中删除。

这只是一种可能的解释。确切地说，需要更详细的日志文件分析和更多的实验。

比如，在那段时间里，在服务器日志中有没有发生过重新认证？
如果 server-side-invalidation 已正确实现，我们可以在受控环境中进行测试吗？