1

我正在使用 node.js + redis 进行会话持久性，但是我注意到在几乎每个 redis 存储或其他会话持久性示例中，您可以配置会话的静态maxAge 或超时。

对我来说，会话​​长度应该基于最后一次交互是有意义的，因此允许我对超时进行更新。Redis 关于其EXPIRE 文档的文档有一个关于刷新超时的部分

刷新会话超时是否设计不好？是否应该始终使用静态超时？

编辑

我最初的问题非常笼统，因为我找不到针对我的具体案例的文档，并且我认为这可能是不好的做法！在查看了源代码后，我终于发现了如何使用 Connect + Node 来做到这一点：

  1. Connect 监听头部end事件（知道更新会话）
  2. 当事件触发时，它要求会话存储保存会话
  3. 特别是作为connect-redis的一部分， save 方法会更新 maxAge

简而言之，我正在寻找错误的文档位置。Connect#session记录了如果为 maxAge 分配了一个新值，会话存储（如 connect-redis）应该如何尊重它。

4

1 回答 1

2

没有糟糕的设计，只有糟糕的选择。

Static Max Timeout
在安全性至关重要的情况下，这是一个不错的选择。使用严格的会话超时，尤其是身份验证，可确保最终用户是预期用户，而不是在主要用户离开他/她的个人电脑或设备时插入的人。这种方法的主要缺点是对用户体验的负面影响。您最不想看到的就是会话在用户即将结帐或做一些重要的事情之前就过时了；对于静态超时，这是不可避免的，并且会经常发生，足以激怒用户。

根据上次访问重置超时
可以肯定地说，大多数网站都使用这种方法，因为它在安全性和用户体验之间提供了良好的平衡。根据上次访问重置会话超时消除了与静态最大超时相关的问题，并且大多数电子商务和银行网站都使用这种方法，因此它肯定是一种公认​​的方法。

不知道您实际上在构建什么，我想说尽管如此，使用重置方法可能是一个不错的选择。出于简洁的原因，您提到的示例可能省略了重置超时，而不是因为它是一个糟糕的设计。

于 2013-05-07T01:13:28.840 回答