设置 session.gc_probability 和 session.gc_divisor 等于 100% 是个坏主意吗？

Question

场景：

• 用户登录
• Cookie 设置为会话长度
• 在闲置 1 小时后，我希望注销用户

我认为我可以如何解决这个问题：

• 将 session.gc_maxlifetime 设置为 1 小时 (3600)
• 将 session.gc_probability 设置为 1
• 将 session.gc_divisor 设置为 1
• 因此可以 100% 确定 1 小时后对任何空闲会话 cookie 进行垃圾收集。

我的问题：

我读过的所有帖子和文档都没有提到将 gc 更改设置为 100%，因此这样做不好吗？有没有更好的办法？

这是一个 symfony 应用程序，从长远来看，我想做这样的事情 http://symfony.com/doc/master/components/http_foundation/session_configuration.html#session-meta-data 但现在我希望只用 session.gc_* 做一些简单的事情

我读过的一篇文章暗示，有 100% 的垃圾收集机会是“成本密集型”How do I expire a PHP session after 30 minutes? 这是真的吗？如果是这样，如何成本密集？

干杯！

Answer 1

gc_probability 和 gc_divisor 可让您定义启动垃圾回收 (GC) 的“概率”。

由于 GC（作为所有东西）都有成本，因此您通常不希望它在服务器处理的每个 Web 请求上运行 - 这意味着每个页面打开或 PHP 提供的每个 AJAX 请求都会导致GC 运行。

因此，根据实际的服务器负载和使用情况，管理员应该对应该多久运行一次 GC 进行有根据的猜测：100 次、1/10000 次或百万次请求中的 1 次。

但是，OP 的原始推理存在一个问题缺陷 - that garbage collection will occur on any idle session。我阅读manual 的方式，垃圾收集将发生在任何会话上，而不仅仅是空闲会话：

session.gc_maxlifetime integer：指定在多少秒后数据将被视为“垃圾”并可能清理。

因此，会话（空闲与否）生命周期由 gc_maxlifetime 决定，而 GC 启动的时刻（如文档中所述：“可能”）实际上由 gc_probability 和 gc_divisor 决定.

要恢复，我对这个问题的较晚回答是 - 在正常情况下，我不会在每个请求（你提到的 1/1 场景）上运行 GC，因为

1. 这似乎是一个严重的矫枉过正。在某种程度上，你可能最终会得到数千个（如果不是更糟的话）IF，并且只有一次进入它的 THEN
2. 您将在 60 分钟后注销系统上的任何用户，而不仅仅是空闲的用户。

Answer 2

有很多更好的方法可以做到这一点。

如果这不是为了特别安全，您可以在客户端set an expiration date/length for the session cookies。在这种情况下，有技术头脑的用户可以调整过期时间，因此您不会想在银行网站上使用它。

如果您需要更安全的东西，只需将过期时间与其他会话数据一起存储并检查。如果超出，请销毁他们的会话并强制他们重新登录。