Confusion over session IDs using Connect

Question

I've been observing session IDs over sequential requests and observed some things I cannot explain:

1) When calling req.sessionID vs. req.cookies["connect.sid"] the values are different (it appears the request.sessionID is magically returning the SID from its associated response - which seems impossible to me).

From my understanding of the Connect source code, req.sessionID is synonymous with the cookie key, why the difference?

2) The first time I make a request from the node server, the browser is issued an SID (let's call this SID1). The next time I connect, the browser is issued SID2. The third and subsequent times I am again issued SID2. Why does node+Connect issue two session IDs before settling down?

Answer 1

The req.sessionID is the same as req.cookies["connect.sid"].

However, if you used supervisor or nodemon, the server is restarted when you modified files. When the server restarts, it will drop all sessions stored by server, but the client didn't clear the old sessionID stored in the cookie. So you can get different sessionIDs.

See this answer for more.

Answer 2

So this is what I have concluded:

1) As the request is going through middleware/modules, I can only assume the current SID is affixed to the request before logging kicks in. This would be a partial explanation as to why req.sessionID might contained SID2, when req.cookies["connect.sid"] contains the previous SID1.

Some caveats:

• This phenomenon is only present when the browser connects for the first time to a new node server instance.

• The browser must have connected to a previous instance of the node server, which issued a cookie with the same key value (e.g. connect.sid).

2) After peeking around the source code for both Sesame and Connect I've come to realise they keep a record of all the sessions IDs they have issued - previously unknown to me. I suspect this is one step towards preventing session fixation.

With that in mind, I realised the SID1 sent in the request during an initial connection was left over from a previous session cookie. Connect would look for a session in its session store matching the SID1 the cookie sent, but as it was a new instance of the node server (just memory sessions here, no persistent sessions ATM), would fail to find it, hence a new SID (SID2) would be issued - this one to stick. Should've thought of this sooner. :)

TL;DR Expected behaviour. Cookies from old sessions are not reused for the sake of security.