[TYPO3-core] RFC #10205: DB session record is only created when user is authenticated

[Michael Stucki]

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
database, 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
   developers).

Attached is a post patch that implements a check for the commerce
extension. However, what if there are more such extensions playing their
own game?

What do you propose?

- michael

Michael Stucki schrieb:
> This is a SVN patch request.
> 
> Priority: urgent!!
> 
> Type: bugfix
> 
> Branches:
> - TYPO3_4-0
> - TYPO3_4-1
> - TYPO3_4-2
> - Trunk
> 
> Bugtracker references:
> http://bugs.typo3.org/view.php?id=10205
> 
> Problem:
>> 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.
> 
> Solution:
> The solution is to check in the "fe_session_data" if the first test
> didn't succeed. This happens at the cost of an additional DB query,
> however I see no way to work around this without making bigger changes.
> 
> - michael
> 


-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bug_10205_post1_commerce.diff
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20090124/00ecbbaf/attachment-0001.txt