TYPO3 Core

From 6. June 04:00 PM to 11. June 02:00 AM it happened 18 times, but with the changed function it did not. I logged this issue with simple log files.

Sven Weiss wrote:

It is possible to get the same sessionId for different users. It actually happened on a high-traffic-site and I could reproduce it on a local test-system with some tweaks in the Core. I analyzed the Core and found out that the "new created sessionId" with createSessionId() is never been checked again the session table/s to found out if it is used for an other user/session. If you get one sessionId which is already defined for an other user/session then your browser keeps it because the session exists and then you have X users with one sessionId.

Now I created a modified version of createSessionId() in t3lib/class.t3lib_userauth.php to check every generated sessionId against the session table/s:
public function createSessionId() {
$createNewSessionId = true;
while($createNewSessionId) {
$sessionId = t3lib_div::getRandomHexString($this->hash_length);
$createNewSessionId = $this->isExistingSessionRecord($sessionId);
}
return $sessionId;
}

It is not the best solution but it works for a hot-fix.
I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)

Sven Weiss wrote:

It is not the best solution but it works for a hot-fix.

It will be the only solution, but we at least we need to optimize the database queries for that, as a normal non-login session

I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)

As this would trigger two database calls for each login, I opt for not using this one...
It does not matter, if the session id is duplicate for non logged in users.
Therefore if would only check if the session Id is duplicate on login - and reset it in case of duplication.

Doing so we save a lot of database queries.

Steffen Ritter wrote:

Sven Weiss wrote:

It is not the best solution but it works for a hot-fix.

It will be the only solution, but we at least we need to optimize the database queries for that, as a normal non-login session

I also found some very old bug tickets which are closed or resolved which are also talking about sessionId problems.

I can really say that it happens! (last time yesterday on a live system, bad!)

As this would trigger two database calls for each login, I opt for not using this one...
It does not matter, if the session id is duplicate for non logged in users.
Therefore if would only check if the session Id is duplicate on login - and reset it in case of duplication.

Doing so we save a lot of database queries.

The sessionId is only saved in database if it is in use (saved some data to it). And then it is very critical if an other (not logged in) user get the same sessionId because then he will use it and can access the same sessionData like the other user. And his client holds the sessionId if it exists.
Security first, then performance. Doing two database calls is the only solution at the moment.

Sven Weiss wrote:

The sessionId is only saved in database if it is in use (saved some data to it). And then it is very critical if an other (not logged in) user get the same sessionId because then he will use it and can access the same sessionData like the other user. And his client holds the sessionId if it exists.
Security first, then performance. Doing two database calls is the only solution at the moment.

Perhaps there is one information missing: I am not talking about users with login. I am using sessions for anonymous users / "users without login".

Tracked this issue in my Logs. Happened very often in the last weeks.
July 2012: 218
August 2012: 131

TYPO3 wanted to give the "in use sessionId" to some other (anonymous) user as often as mentioned.