iOS 偶尔发送旧 cookie
iOS sporadically sends old cookies
我有一个定期轮换身份验证令牌 cookie 值的应用程序。
每次服务器轮换令牌时，它不会将其标记为"good"，直到它看到客户端拥有令牌（因为客户端将其包含在对资源的请求headers中） .
我只在 iOS (10.3) 上有一个非常特殊的情况，当网络条件发生变化时（例如：下地铁），它偶尔会发送一个非常旧的 cookie。当此条件命中时，"forgets" 关于最近的 cookie 值和 "starts living in the past" 并发送旧值。
** 安全说明：IP 地址在纽约市 t-mobile 公开分配，令牌早已从我们的数据库中删除
- 这是一个已知问题吗？
- 是否有任何在 iOS 上更可靠的 cookie 处理变通办法？ localstorage 并不理想，因为这些 cookie 仅为 http。
澄清一下……流程是这样的：
- 客户端（iOS Safari）有一个名为
_t 的 cookie，其值为 old
- 客户端（iOS Safari）向服务器发出请求
- 我们发出
Set-Cookie 并将 _t cookie 设置为新值 new（仅限 http，安全 cookie）
- 客户端使用新的 cookie 值
new 发出另一个请求。我们标记 cookie 值是好的并且客户端有它。
- 时光荏苒
- 客户端使用值为
old 的 _t cookie 发出请求
这是我对发生的事情的理论：
从cookie的生命周期来看，每当用户身份验证状态发生变化（登录用户->注销用户||注销用户->登录用户）时，旧cookie将失效并被新cookie取代。
但为什么会发生在地铁而不是其他地方呢？
1. 如今，大多数地铁都提供免费的不安全 WiFi，以补充地下糟糕的无线网络连接。
2. 在 10.3 中有一些关于网络连接问题的报告，以及
this one 特别有趣，因为问题是 location dependent。
3. 我认为上述 (1) 和 (2) 的组合导致应用程序重新向服务器进行身份验证。也许您可以提取日志以检查是否确实如此？
可能的解决方法？
也许 none。
我们无法阻止 iPhone 用户进行 iOS 升级。大多数人已经这样做了。
此外，在重新验证后不更改 cookie 的安全影响更糟。
根据截至 2017 年 5 月 31 日的评论更新：
鉴于评论中的详细信息。我们可以有更好的解释。
在 cookie 生命周期中，当用户注销时，server-side-invalidation 应该发生。
工作流程：
1.当用户logout时，authenticated sessionID从浏览器中删除。
2. 但这还不够。服务器也需要 invalidate 那 sessionID。否则可能会产生安全影响。
3.在您的情况下，服务器可能没有失效。因此它仍然期待 SessionID 已经是 deleted from the browser。
这只是一种可能的解释。确切地说，需要更详细的日志文件分析和更多实验。
例如，在那段时间里，在服务器日志中是否发生了重新验证？
如果 server-side-invalidation 已正确实施，我们可以在受控环境中进行测试吗？
SQLite 数据库，如果你愿意牺牲一点安全性。
我的经历
我还使用 ID 进行身份验证，ID 随每个请求而变化并存储在 cookie 中。
我可以确认这种行为，它仍然存在于 iOS 11（和 iOS 11.1 beta 3）中。在我的日志文件中，我可以看到有时旧的 cookie 会随机存储在 Safari 中。当关闭并重新打开独立的 webapp 时，会发生这种情况。
我的后备方法
我在 localStorage 上构建了一个后备方法。带有旧 cookie 的请求通常会将我数据库中的所有数据标记为无效。如果用户代理指向带有 iOS 的设备，我不会将数据标记为无效并让客户端再次尝试验证自己。
在客户端，我检查 localStorage 并使用此数据创建新的 cookie。随后，将进行新的身份验证。 localStorage 像每个请求的 cookie 一样被重写。如果身份验证再次失败，我将数据标记为无效。
Safari View Controller 在 iOS 11 及更高版本中不再与 Safari 共享 cookie，此更改解决了困扰 iOS 的 cookie 存储损坏问题。自 iOS 11 发布以来，我们从未遇到过此问题。
可能是自动重试造成的？
这些帖子提到在糟糕的网络条件下可能会发生这种情况（就像你说的，地铁）：
https://medium.com/@fagnerbrack/the-day-a-bug-was-fixed-only-because-the-ceo-called-in-f653a34079eb
https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries
我有一个定期轮换身份验证令牌 cookie 值的应用程序。
每次服务器轮换令牌时，它不会将其标记为"good"，直到它看到客户端拥有令牌（因为客户端将其包含在对资源的请求headers中） .
我只在 iOS (10.3) 上有一个非常特殊的情况，当网络条件发生变化时（例如：下地铁），它偶尔会发送一个非常旧的 cookie。当此条件命中时，"forgets" 关于最近的 cookie 值和 "starts living in the past" 并发送旧值。
** 安全说明：IP 地址在纽约市 t-mobile 公开分配，令牌早已从我们的数据库中删除
- 这是一个已知问题吗？
- 是否有任何在 iOS 上更可靠的 cookie 处理变通办法？ localstorage 并不理想，因为这些 cookie 仅为 http。
澄清一下……流程是这样的：
- 客户端（iOS Safari）有一个名为
_t的 cookie，其值为old - 客户端（iOS Safari）向服务器发出请求
- 我们发出
Set-Cookie并将_tcookie 设置为新值new（仅限 http，安全 cookie） - 客户端使用新的 cookie 值
new发出另一个请求。我们标记 cookie 值是好的并且客户端有它。 - 时光荏苒
- 客户端使用值为
old 的
_t cookie 发出请求
这是我对发生的事情的理论：
从cookie的生命周期来看，每当用户身份验证状态发生变化（登录用户->注销用户||注销用户->登录用户）时，旧cookie将失效并被新cookie取代。
但为什么会发生在地铁而不是其他地方呢？
1. 如今，大多数地铁都提供免费的不安全 WiFi，以补充地下糟糕的无线网络连接。
2. 在 10.3 中有一些关于网络连接问题的报告，以及
this one 特别有趣，因为问题是 location dependent。
3. 我认为上述 (1) 和 (2) 的组合导致应用程序重新向服务器进行身份验证。也许您可以提取日志以检查是否确实如此？
可能的解决方法？
也许 none。
我们无法阻止 iPhone 用户进行 iOS 升级。大多数人已经这样做了。
此外，在重新验证后不更改 cookie 的安全影响更糟。
根据截至 2017 年 5 月 31 日的评论更新：
鉴于评论中的详细信息。我们可以有更好的解释。
在 cookie 生命周期中，当用户注销时，server-side-invalidation 应该发生。
工作流程：
1.当用户logout时，authenticated sessionID从浏览器中删除。
2. 但这还不够。服务器也需要 invalidate 那 sessionID。否则可能会产生安全影响。
3.在您的情况下，服务器可能没有失效。因此它仍然期待 SessionID 已经是 deleted from the browser。
这只是一种可能的解释。确切地说，需要更详细的日志文件分析和更多实验。
例如，在那段时间里，在服务器日志中是否发生了重新验证？
如果 server-side-invalidation 已正确实施，我们可以在受控环境中进行测试吗？
SQLite 数据库，如果你愿意牺牲一点安全性。
我的经历
我还使用 ID 进行身份验证，ID 随每个请求而变化并存储在 cookie 中。 我可以确认这种行为，它仍然存在于 iOS 11（和 iOS 11.1 beta 3）中。在我的日志文件中，我可以看到有时旧的 cookie 会随机存储在 Safari 中。当关闭并重新打开独立的 webapp 时，会发生这种情况。
我的后备方法
我在 localStorage 上构建了一个后备方法。带有旧 cookie 的请求通常会将我数据库中的所有数据标记为无效。如果用户代理指向带有 iOS 的设备，我不会将数据标记为无效并让客户端再次尝试验证自己。
在客户端，我检查 localStorage 并使用此数据创建新的 cookie。随后，将进行新的身份验证。 localStorage 像每个请求的 cookie 一样被重写。如果身份验证再次失败，我将数据标记为无效。
Safari View Controller 在 iOS 11 及更高版本中不再与 Safari 共享 cookie，此更改解决了困扰 iOS 的 cookie 存储损坏问题。自 iOS 11 发布以来，我们从未遇到过此问题。
可能是自动重试造成的？ 这些帖子提到在糟糕的网络条件下可能会发生这种情况（就像你说的，地铁）：
https://medium.com/@fagnerbrack/the-day-a-bug-was-fixed-only-because-the-ceo-called-in-f653a34079eb
https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries