【问题标题】:Chrome is creating duplicate sessions with the same idChrome 正在创建具有相同 ID 的重复会话
【发布时间】:2012-06-12 20:54:45
【问题描述】:

我今天在修改会话库时遇到了一个问题,这可能是我第一次在后端脚本上看到特定于浏览器的问题。我希望有人能解释一下。

会话库的基本工作方式是:实例化时,它会在客户端计算机上检查名为“id”的 cookie(以 uniqid 结果的形式)。如果找到 cookie,脚本会检查该 cookie 以及用户代理字符串的散列副本与会话表中的条目。如果找到匹配条目,脚本将恢复会话。如果没有找到名为 'id' 的 cookie,或者会话表中不存在匹配条目,则脚本会同时创建两者。我认为相当标准。

现在是奇怪的部分:在 Firefox 中,一切都按预期运行。用户获得一个会话,只要未超过 24 小时不活动,他将始终在连接后恢复该会话。但是当我在 Chrome 中访问该页面时,即使它看起来相同并且似乎以相同的顺序执行查询,我在会话表中看到两个条目。会话共享一个代理字符串,但 id 不同,时间戳日志表明幽灵会话是在为用户创建会话之后不久(一秒内)创建的。

出于调试目的,我一直在执行查询时将查询打印到屏幕上,这是我在 Chrome 应该打开一个会话而以某种方式打开两个会话时看到的示例:

// Attempting to resume a session
SELECT id FROM sessions WHERE id = '4fd24a5cd8df12.62439982' AND agent = '9bcd5c6aac911f8bcd938a9563bc4eca'

// No result, so it creates a new one
INSERT INTO sessions (id, agent, start, last) VALUES ('4fd24ef0347f26.72354606', '9bcd5c6aac911f8bcd938a9563bc4eca', '1339182832', '1339182832')

// Clear old sessions
DELETE FROM sessions WHERE last < 1339096432

这是我后来在数据库中看到的:

id, agent, start, last
4fd24ef0347f26.72354606, 9bcd5c6aac911f8bcd938a9563bc4eca, 1339182832, 1339182832
4fd24ef0857f94.72251285, 9bcd5c6aac911f8bcd938a9563bc4eca, 1339182833, 1339182833

我是否遗漏了一些明显的东西?我唯一能想到的是 Chrome 可能会在后台创建一个隐藏会话,可能是为了抓取页面。但是,如果是这种情况,当我开始将活动会话与用户表中的条目相关联时,它可能会在以后成为问题。我一直在寻找我的脚本中可能存在的错误,但到目前为止我还没有发现任何东西,并且在 Firefox 中一切正常。

【问题讨论】:

  • dlwiest 你问了 8 个问题,但没有将其中任何一个标记为已回答...
  • @dlwiest 你看到我的链接了吗?这个问题似乎从 2011 年初就存在了。
  • 我只是在看那个。所以这是我应该担心的事情吗?我担心的是,如果 Google 这样做是为了抓取页面,那么当我开始将会话 ID 存储在用户表中以指示用户当前已登录时,它将遇到问题;幽灵会话不会登录,而用户会话会登录。
  • 好吧,向我们展示如何获取和设置数据可能是个好主意。也许你在 php 本身中处理会话的方式有问题

标签: php google-chrome cookies


【解决方案1】:

我以前也遇到过这种情况,同样感到困惑。从几个月前开始,Chrome 就启用了预取功能。因此,为了加快用户的感知速度,它会抓取页面上的大多数链接,并提前部分检索和呈现它们。非常适合最终用户,因为如果您使用宽带,它确实可以减少页面更改时间。

不幸的是,对于我们 Web 开发人员来说,它会导致像上面这样的混乱。例如,当 Chrome 用户访问网站但尚未分配 cookie 或会话,但浏览器已预取多个页面并分配了多个会话时,就会发生这种情况。

假设某人访问了一个页面,其中包含指向您 PHP 脚本不同区域的链接,并且该脚本旨在为所有访问者分配一个 cookie……如果 Chrome 同时或接近它获取其中两个页面,PHP 将最终分配不同的会话,因为 Chrome 中的另一个线程在完成另一个分配之前基本上需要一个新的会话/cookie。

我知道有两种解决方案:一种是Google's JavaScript API for handling prerendering,我还没有发现它特别好。另一种方法是在从 PHP 分发会话和 cookie 时执行更严格的检查。要么不将会话分配给来宾用户,要么添加一些额外的检查(IP、主机名等)。

希望对您有所帮助。

【讨论】:

  • 我的会话脚本会根据用户的 IP + 代理信息生成一个哈希,并且对于预取会话不会改变,所以我不确定如何过滤这种方式。如果 Chrome 在预取时发送某种标头会很好。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-11-30
  • 2011-01-15
  • 2011-01-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多