5

我已经为“记住我”选项实施了改进的持久登录 Cookie 最佳实践。

当请求按顺序排列时（传统的页面加载），这可以正常工作。在这种情况下，您可以确定下一个请求将具有相同的系列标识符和服务器上次发送的令牌。

但是在 AJAX 请求的情况下，多个请求同时来自同一个浏览器，第一个请求将导致生成一个新的令牌编号。但是其他请求不会有这个新生成的令牌号，我们会拒绝访问，将其视为盗窃。

我们如何解决这个问题？

4

3 回答 3

1

基于上述 Drupal 线程（https://www.drupal.org/node/327263#comment-3428038）上提出的解决方案，我想知道我们是否不能有一个更简单的算法。

为什么不使用当前用户会话，而不是将“旧”替换令牌存储在短暂的缓存表中？

1. User logs in with PL cookie
If series & token are in PL table:
  2. User session is populated with the last valid token
  3. new token is given to client
  4. user is logged in
If series key is in PL table, but token is not:
  2. check if current user session still holds the latest replaced token
  If found:
    3. user is logged in.  No new token is provided since one was generated in the first request.
  If not found:
    3. Assume keys are stolen - series is destroyed

但是，当会话状态未正确复制到所有节点时，此算法在负载平衡场景中不起作用！

于 2017-04-23T21:01:05.433 回答
0

我认为您将记住我与 CSRF（跨站点请求伪造）保护令牌混淆了。CSRF 令牌通过禁用未经身份验证的“功能执行”的可能性来保护应用程序。他们通过向每个响应发出不可推断的令牌，并在收到请求时对其进行验证来做到这一点。

记住我功能是一项允许用户登录的功能，即使原始会话早已不复存在。无需再次提供他的用户名/密码。您应该在每次成功登录时设置一次或一次记住我的令牌。不是在每个回应中。您没有在每个响应中设置会话 cookie 为什么要设置记住我的令牌？

于 2012-11-28T20:21:01.897 回答
0

因为我有同样的问题，所以我一直在读一些关于这个的东西。

Barry Jaspan 和 Charles Miller 的技术似乎无法使用（尤其是在 AJAX 设置中），因为正如您所指出的那样，在服务器上生成新令牌和将其应用到 cookie 之间，可能会发生很多事情。

在我们的例子中，它是异步的，但在其他情况下，值可能不会在 cookie 中结束，因为它存储在服务器上（例如，在加载之前离开页面）。

巴里似乎承认这一点。

其次，使令牌失效（例如在密码更改时）会使您最终得到很多“幽灵”cookie。其中一个的每次访问都会使所有其他会话无效（此时可能在其中有有效的会话）。

由于这些限制，我认为最好的解决方案是以下组合：

  • HTTPS (SSL) 使用
  • 这种技术，但没有在每个请求上重新生成
  • 跟踪用户失效（处理上面的第二条评论）
  • 仅 HTTP cookie（以避免脚本访问它们）

我已向 Barry 发送了一条消息，以考虑在他的页面上发布有关此问题的通知。

于 2013-02-12T10:43:18.870 回答