使用连接混淆会话ID
我一直在观察顺序请求的会话ID，并观察了一些我无法解释的事情：
1）当调用req.sessionID与req.cookies["connect.sid"] ，值是不同的（ 看起来 request.sessionID神奇地从其关联的响应返回SID – 这似乎是不可能的）。
从我对Connect源代码的理解中， req.sessionID与cookie关键字是同义词，为什么有所不同？
2）第一次从节点服务器发出请求时，浏览器被发出一个SID（我们称之为SID1）。 下一次我连接，浏览器被发布SID2。 第三次及以后，我再次发行SID2。 为什么node + Connect在build立之前发出两个会话ID？
所以这就是我所得出的结论：
1）当请求正在通过中间件/模块时，我只能假设当前的SID被添加到了请求中 。 当req.cookies["connect.sid"]包含之前的SID1时，这将是为什么req.sessionID可能包含SID2的部分解释。
一些注意事项：
-
只有当浏览器首次连接到新的节点服务器实例时，才会出现这种现象。
-
浏览器必须已连接到节点服务器的前一个实例，该服务器使用相同的键值（例如
connect.sid）发出一个cookie。
2）偷看芝麻和连接的源代码后，我发现他们logging了他们发布的所有会话ID – 以前我不知道。 我怀疑这是防止会话固定的一步。
考虑到这一点，我意识到在初始连接期间，请求中发送的SID1是从以前的会话cookie中遗留下来的。 Connect会在其会话存储中查找匹配发送cookie的SID1的会话，但由于它是节点服务器的新实例（这里只是内存会话，没有持久会话ATM）将无法find它，因此会有一个新的SID （SID2）将发布 – 这一个坚持。 应该早点想到这个。 🙂
TL; DR预期的行为。 来自旧会话的cookie不会为了安全而重用。
req.sessionID与req.cookies["connect.sid"] 。
但是，如果使用了supervisor或nodemon ，则在修改文件时将重新启动服务器。 当服务器重新启动时，它将删除服务器存储的所有会话，但客户端不清除存储在cookie中的旧sessionID。 所以你可以得到不同的会话ID。
看到这个答案更多。