Chrome正在创建具有相同ID的重复会话 [英] Chrome is creating duplicate sessions with the same id

问题描述

我在今天修改会话库时遇到了问题，这可能是我第一次看到后端脚本中的浏览器特定问题。我希望有人能提供一些线索

I encountered an issue while I was revising my session library today, and this might be the first time I've ever seen a browser-specific problem on a back end script. I hope somebody can shed some light.

基本上如何在会议库的工作原理是：实例化时，它会检查一个名为ID（在uniqid形式的cookie结果）在客户端机器上。如果找到cookie，脚本将根据会话表中的条目检查用户代理字符串的哈希副本和哈希副本。如果找到匹配的条目，脚本将恢复会话。如果没有找到名为id的cookie，或者会话表中不存在匹配的条目，则脚本将创建两者。相当标准，我想。

Basically how the session library works is: when instantiated, it checks for a cookie called 'id' (in the form of a uniqid result) on the client machine. If a cookie is found, the script checks that and a hashed copy of the user agent string against entries in a session table. If a matching entry is found, the script resumes the session. If no cookie named 'id' is found, or if no matching entry exists in the sessions table, the script creates both. Fairly standard, I think.

现在这里是奇怪的部分：在Firefox中，一切正常预测。用户获得一个会话，他将永远恢复连接，只要24小时的不活动尚未过去。但是当我访问Chrome中的页面时，即使它看起来相同，并且似乎以相同的顺序执行查询，我在会话表中看到两个条目。会话共享一个代理字符串，但是ids不同，时间戳日志表示在为用户创建的会话之后不久（在一秒钟内）创建了ghost会话。

Now here's the weird part: in Firefox, everything works as predicted. The user gets one session, which he'll always resume upon connection, as long as 24 hours of inactivity has not elapsed. But when I visit the page in Chrome, even though it looks the same and appears to be executing queries in the same order, I see two entries in the session table. The sessions share an agent string, but the ids are different, and timestamp logs indicate that the ghost session is being created shortly (within a second) after the one created for the user.

为了进行调试，我已经在执行时向屏幕打印查询，这是我在Chrome看到的一个示例，当Chrome应该打开一个会话，并以某种方式打开两个：

For debugging purposes, I've been printing queries to the screen as they're executed, and this is an example of what I'm seeing when Chrome should be opening one session and is somehow opening two instead:

// 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

和这里就是我在数据库中我看到之后：

And here's what I'm seeing in the database afterward:

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

我缺少明显的东西吗？我唯一能想到的是，Chrome可能在后台创建一个隐藏会话，可能抓取页面。如果是这样，它可能会成为一个问题，以后，当我开始关联活动会话与用户表中的条目。我一直在寻找可能的错误在我的脚本，但我还没有找到任何到目前为止，一切工作正如预期在Firefox。

Am I missing something obvious? The only thing I can think of is that Chrome might be creating a hidden session in the background, possibly to crawl the page. If that's the case though, it could become a problem later, when I begin associating active sessions with entries in the users table. I've been looking for possible bugs in my script, but I haven't found anything so far, and everything works as expected in Firefox.

推荐答案

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

I have run into this before and was equally confused. Since a few months ago Chrome has prefetching enabled. So to speed up perceived speed to users, it crawls most links on the page and retrieves and renders them partially in advance. Great for end users since if you're on broadband it can really reduce page change times.

不幸的是，对于我们的网络开发者，它导致混乱像上面。例如，当Chrome用户访问网站，尚未分配Cookie或会话，但浏览器已预先抓取多个网页，并且已分配多个会话时。

Unfortunately for us web developers, it leads to confusion like the above. This happens for example when a Chrome user visits a website and has not yet been assigned a cookie or session, but the browser has pre-fetched multiple pages and been assigned multiple sessions.

因此，假设有人访问一个页面，其中包含指向PHP脚本不同区域的链接，并且该脚本旨在为所有访问者分配Cookie ...如果Chrome同时或同时访问其中的两个页面，PHP将结束因为Chrome中的另一个线程在完成其他任务之前基本上需要新的会话/ Cookie。

So let's say someone visits a page with links to different areas of your PHP script, and the script is designed to assign a cookie to all visitors...if Chrome fetches two of those pages simultaneously or close to it, PHP will end up assigning different sessions because another thread in Chrome will basically require a new session/cookie before the other assignment has been completed.

我知道有两个解决方案：一种是谷歌的的JavaScript API处理预呈现，我还没有发现特别好。另一种方法是在从PHP传递会话和Cookie时执行更严格的检查。

There are two solutions I'm aware of: One is Google's JavaScript API for handling prerendering, which I haven't found to be particularly good. The other way is to perform more stringent checking when handing out sessions and cookies from PHP. Either don't assign sessions to guest users, or add some additional checks (IP, hostname, whatever).

希望有帮助。

这篇关于Chrome正在创建具有相同ID的重复会话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！