DB session records are only created when users authenticate
Functions $GLOBALS["TSFE"]->fe_user->getKey() or $GLOBALS["TSFE"]->fe_user->setKey() allow to bind data to a user's session.
Unfortunately TYPO3 only creates DB session records in tables be_sessions/fe_sessions if a user authenticates.
Before applying the session fixation fix, TYPO3 always trusted the session id provided by the user through COOKIE etc. Although no DB session records were created, setKey() and getKey() worked in a way that a record in fe_session_data was created (including session id) and could be accessed.
Now, after the session fixation fix, TYPO3 will issue a new session id if there's no according db record in be_sessions/fe_sessions. This now has the drawback that every request of a non-authenticated user will force TYPO3 to issue a new session id so that getKey() no longer works as existing records in fe_session_data are associated to an "old" session identifier.
I believe that the security fix is not the cause of the problem but the trigger for it. I expect TYPO3 to create a DB session record whenever a session id is generated not only when a user authenticates itself.
(issue imported from #M10205)
#1 Updated by Marcus Krause over 8 years ago
There are two possible solutions:
- let method isExistingSessionRecord() check both tables fe_sessions/be_sessions AND fe_session_data for existing session ids
- let TYPO3 create be_sessions/fe_sessions records also for non-authenticated users
My favourite is #2; what do you think?
#4 Updated by Dmitry Dulepov over 8 years ago
Uploaded a simple script to test&reproduce the problem. The following TS should be added to the site TS to see it in action:
includeLibs.user_sestest = fileadmin/user_sestest.php page.5 = USER_INT page.5.userFunc = user_sestest
The output will display previous and new value (time stamp actually). With older TYPO3 code both values were shown. Current trunk shows only the new value (old one is always empty).
#5 Updated by Christian Hernmarck over 8 years ago
Just a note:
this bug/topic is important - I upgraded to Typo3 4.0.10, 4.1.8 and 4.2.4 (several installations on several servers) and later realized that the shop is not working anymore (basket always empty).
Maybe my fault (I didn't check everything on the new version) - but it seems that the updates are more and more problematic...
#10 Updated by Helmut Hummel over 8 years ago
I'm not too happy about storing every anonymous session into the database. This could lead to a serious performance impact an high traffic sites.
So, I would vote for solution #1 to avoid unnecessary load on the server.
A compromise would be to only store the session id in fe_sessions, if $this->sesData_change is set and data is written to fe_sessions_data table...
But I'm not sure on this ...
#16 Updated by Franz Holzinger over 8 years ago
tt_products basket: The patch 10205_trunk.diff for the trunk works fine, but only tt_products 2.8.0. It does not work with tt_products 2.5.10.
The patch 10205.diff for TYPO3 4.2.4 does not change anything. The table fe_session_data always remains empty.
#17 Updated by Manfred Mueller-Spaeth over 8 years ago
The problem comes in another "flavour" for me: fe_users may login, but on the next request, they seem to be logged out.
The workaround mentioned above works fine in this case, but not the hotfix 10205.diff, this won't change anything on the problem described above.
Edit: TYPO3 4.2.4 - PHP 5.2.x - tested with FireFox on Mac OS X and Windows
Edit: Sorry, I made a mistake, now the hotfix works fine!
#19 Updated by Michael Stucki over 8 years ago
By having a look at patch "10205.diff" I think it is not solving the problem correctly.
1) Although such session information is most likely stored in FE sessions only, there is no guarantee for this. At least checking the ->loginType is the wrong way in my opinion.
2) Instead of doing a select query in the fe_session_data table, I propose to simply check the client session lifetime. Every value which is more than 0 should have a corresponding record in fe_session, and vice versa, if the lifetime is 0 we can be sure it's a non-authenticated session.
Those who tried the old patch already, please re-test if the new solution from "bug_10205_v2.diff" will also work for you. Thanks in advance!
#31 Updated by Jens Hirschfeld over 8 years ago
I've tested the patch bug_10205_v3.diff.
To reproduce the Problem with the login being not possible with the patch bug_10205_v3.diff:
1. go to the fe-login page.
2. delete your fe_typo_user cookie
3. login (it looks like it is successful)
4. click any link in your page. You aren´t logged in any more.
How the login is possible:
1. delete your fe_typo_user cookie
2. go to any page on your site, which contains an extension, which saves session-data.
3. now go to the fe-login page.
4. login -> the login IS successful
[Wrong, don´t read it!]
This Part of the Note is wrong:
I've tested the patch bug_10205_v3.diff on different server (2x IIS and 1x Apache).
The patch worked on the Apache Server, but on IIS Server I have encountered the Problem, that no FE-User can log in!
The user types in the username in password. After clicking the "login" Button/Link the User is again on the "login" page.
If i replace the patched Files with the original ones, the login is again possible.
[/Wrong, don´t read it!]
The reason was, that on the IIS-Systems i had´nt already a cookie with Session-Data. On the Apache-System i did.
#32 Updated by Manfred Mueller-Spaeth over 8 years ago
I thought all went fine, but I'm wrong ...
It's a curious thing: after using the system with the workaround above (just commenting out the call of "isExistingSessionRecord") and then patching the file (made unchanged again before), all works fine, also with deleted cookies. That's what I wrote yesterday in my comment.
But after truncating fe_session and fe_session_data, the same behaviour came up: fe_user login possible, but "forgotten login" with the next request.
Because of the lack of time, for the moment my description is not very precise. If no solution is found, I will track it with more details begin of next week.
#33 Updated by Benno Weinzierl over 8 years ago
bug_10205_v3.diff did fix my 4.1.8-Installation.
It is a realy urgent matter as i also updated over 10 Projects until i noticed the disaster. There should be a Warning at the download-Page of www.typo3.org until this is fixed... just to prevent others to do the same mistake that i did.
Edit: Sorry, patch does NOT work in IE6&7. Users are only logged in for one request. => i think same thing as Manfred Mueller-Spaeth
#34 Updated by Michael Stucki over 8 years ago
Finally found the reason why this works on some sites and and some it doesn't. My assumption regarding $lifetime was wrong. It is no indication for a non-authenticated user.
Therefore I'm uploading a new patch which doesn't have this condition and should finally work for all scenarios.
#36 Updated by Manfred Mueller-Spaeth over 8 years ago
I'm really sorry ... but it's the same erroneous behaviour as before ...
After patching a freshly unzipped 4.2.4 with v4 and clearing all caches in TYPO3 as well as the cookies and sessions in the browser (FireFox) and emptying fe_sessions and fe_session_data, it's the same problem: a fe_user may login, but the next request on a secured page causes an error "The page did not exist or was inaccessible. Reason: ID was not an accessible page" as always.
Again: if there are sessions in the table from using the workaround above (commenting out the part " || !$this->isExistingSessionRecord($id)", the login works correctly without the workaround though. It's curious.
#37 Updated by Michael Stucki over 8 years ago
Oh well... What a mess!
After verifying the patch on a clients site, I can confirm that it
works, however there are still more problems to be resolved.
The extension "commerce" does for some reason use its own session
table, meaning there is no content in fe_session, no content in
fe_session_data, but there is content in tx_commerce_baskets!
Now the question is, how should we treat that situation:
a) Ignore but warn users of that extension
b) Add a fix for commerce to the core - see attached patch
c) Add a configuration flag that disables the session fixation fix (so
that the user gets more time to wait for a fix from the commerce
Attached is a post patch that implements a check for the commerce
extension. However, what if there are more such extensions playing their
What do you propose?