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

[Ingmar Schlecht]

Hi folks,

I have done some more work (including testing) on this and created a
combined patch of Stucki's two patches and added a little @deprecated
comment to the specific commerce fix.

I know that this is not nice stuff to have in the core, but I think for
such an urgently waited-for fix it is better to make it compatible with
more installations (i.e. including those with commerce installed) than
wait for the extension authors to work around this in their extensions.

Therefore I am a strong supporter of having this commerce specific bit
of code with the appropriate @deprecated comment in the core and remove
it some time later when a fixed commerce version is available.

I will commit this fix later today and then release the bunch of patch
level versions people are waiting for.

cheers
Ingmar


Michael Stucki schrieb:
> 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
>>
> 
> 


-- 
Ingmar Schlecht
TYPO3 Core Developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug_10205_v5.patch
Type: text/x-diff
Size: 2711 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20090124/7ff43d43/attachment-0001.patch