为什么会话存储具有静态超时/ maxAge

Question

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

对我来说，会话​​长度应该基于最后的交互，因此允许我对超时进行更新。 Redis关于EXPIRE documentation的文档有一节关于刷新timeoutl

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

修改

我原来的问题非常笼统，因为我找不到具体案例的文件，我想也许这是不好的做法！在查看源代码后，我终于发现了如何使用Connect + Node执行此操作：

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

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

Answer 1

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

静态最大超时
安全性至关重要的好选择。使用紧密的会话超时（尤其是使用身份验证）可确保最终用户是预期用户，而不是在主要用户离开他/她的PC或设备时插入的用户。这种方法的主要缺点是对用户体验的负面影响。你想要的最后一件事就是在用户即将结账或做重要事情之前会话过时了;在静态超时的情况下，这是不可避免的，并且经常发生，足以惹恼用户。

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

不知道你实际建造的是什么，我认为采用重置方法可能是一个不错的选择。您提到的示例可能会因为简洁原因而忽略重置超时，而不是因为这是一个糟糕的设计。