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

Steffen Kamper info at sk-typo3.de
Sat Jan 24 14:44:49 CET 2009


Hi Ingmar,

thanks for your engagement!

vg Steffen

Ingmar Schlecht schrieb:
> 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
>>>
>>
> 
> 


More information about the TYPO3-team-core mailing list