10

场景：

  • 用户登录
  • 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% 的垃圾收集机会是“成本密集型”的如何在 30 分钟后使 PHP 会话过期？这是真的？如果是这样，成本密集程度如何？

干杯!

4

2 回答 2

7

并且可以让您定义启动垃圾收集 (GC) 的“概率” gc_probability。gc_divisor

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

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

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

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

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

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

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

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

如果这不是为了特别安全，您可以在客户端设置会话 cookie 的到期日期/长度。在这种情况下，有技术头脑的用户可以调整过期时间，因此您不想在银行网站上使用它。

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

于 2013-11-11T17:21:07.427 回答