我一直在观察顺序请求的会话ID,并观察了一些我无法解释的事情:
1)当调用req.sessionID与req.cookies["connect.sid"]该值不同(它出现的request.sessionID奇迹般地返回来自其相关响应SID -这似乎是不可能的我).
从我对Connect源代码的理解,req.sessionID是cookie密钥的同义词,为什么会有区别?
2)我第一次从节点服务器发出请求时,会向浏览器发出一个SID(让我们调用这个SID1).下次连接时,浏览器会发出SID2.第三次及以后我再次发布SID2.为什么node + Connect在安定之前会发出两个会话ID?
所以这就是我的结论:
1)当请求通过中间件/模块时,我只能假设在记录踢入之前将当前SID附加到请求.这将是部分解释为什么req.sessionID可能包含SID2,当req.cookies["connect.sid"]包含先前的SID1时.
一些警告:
仅当浏览器第一次连接到新节点服务器实例时才会出现此现象.
浏览器必须已连接到节点服务器的先前实例,该实例发出具有相同键值的cookie(例如connect.sid).
2)在浏览Sesame和Connect的源代码后,我意识到他们记录了他们发布的所有会话ID - 以前我不知道.我怀疑这是防止会话固定的一步.
考虑到这一点,我意识到在初始连接期间在请求中发送的SID1是从先前的会话cookie中遗留下来的.Connect会在其会话存储中查找与发送的cookie匹配的SID1的会话,但由于它是节点服务器的新实例(这里只是内存会话,没有持久会话ATM),因此无法找到它,因此是新的SID (SID2)将被发布 - 这一个坚持.应该早点想到这个.:)
TL; DR预期行为.旧会话中的Cookie不会为了安全起见而重复使用.
| 归档时间: |
|
| 查看次数: |
7045 次 |
| 最近记录: |