为什么会议商店有静态超时/ maxAge
我使用node.js + redis进行会话持久性，但是我注意到几乎在每个redis存储或其他会话持久性的例子中，都有一个静态 maxAge或会话超时，您可以configuration。
对我来说，会话长度应该基于最后一次交互是有意义的，从而允许我对超时进行更新。 Redis关于其EXPIRE文档的文档有一个关于刷新timeoutl的部分
刷新会话超时devise不好？ 应该始终使用静态超时？
编辑
我原来的问题是非常一般的，因为我找不到我的具体案例的文件，我认为这可能是不好的做法！ 在查看源代码之后，我终于发现了如何使用Connect + Node进行此操作：
- 连接监听头
end事件（知道更新会话） - 事件触发时，会要求会话存储保存会话
- 作为connect-redis的一部分，save方法更新maxAge
总之，我正在看错文件的地方。 连接＃会话文档，如果maxAge被分配了一个新的值，会话存储（如connect-redis）应该遵守。
没有不好的devise，只有不好的select。
静态最大超时
安全性是最重要的一个很好的select。 使用严格的会话超时（尤其是使用身份validation）可以确保最终用户是预期的用户，而不是在主要用户远离他/她的电脑或设备时放入的用户。 这种方法的主要缺点是对用户体验有负面影响。 你想要的最后一件事是在用户即将结账或做重要事情之前，会话将会陈旧; 在静态超时的情况下，这是不可避免的，并且会经常发生，以致于不能使用用户。
根据上次访问重置超时
可以肯定地说大多数网站使用这种方法，因为它提供了安全和用户体验之间的良好平衡。 根据上次访问重置会话超时消除了与静态最大超时有关的问题，大多数ecom和银行网站都使用这种方法，所以这肯定是一种可接受的方法。
不知道你在做什么，我想说重置方法可能是一个不错的select。 你提到的例子可能会省略重置超时的原因，而不是因为它是一个糟糕的devise。