[TYPO3-core] RFC: #17490: After introducing the locking in #17289 no CSRF token will ever be deleted.

Helmut Hummel helmut.hummel at typo3.org
Sat Feb 5 00:30:45 CET 2011


Hi!

This is an SVN patch request.

Type: Bugfix

Bugtracker references:
http://bugs.typo3.org/view.php?id=17490

Branches:
4-5, trunk


Problem:
After introducing the locking in 0017289, fetching the probably updated
token array and merging this with the token array of the current
request, all tokens that have been unset during this request are again
added to the array (they are present in the fetched array of tokens).

Solution:
Keep track which tokens are added and deleted during the request and
update the token array accordingly.

Note:
Since we now know if changes are made to the token array during one
request, we could simply skip the locking and persisting, which saves
quite some time for modules that do not create or validate tokens (which
most modules do not do).

Additional remark on the unit tests:
The patch for the extended unit tests also contain the fixes which are
part of RFC #17342, just to make the unit tests work. If you apply the
unit test patch only, you'll see one test fail. If you then apply the
regular patch, the unit test should turn into green again.


Kind regards,
Helmut

-- 
Helmut Hummel
TYPO3 Security Team Leader

TYPO3 .... inspiring people to share!
Get involved: typo3.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 17490.diff
Type: text/x-patch
Size: 3577 bytes
Desc: not available
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20110205/af695df0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 17490_unittests.diff
Type: text/x-patch
Size: 3280 bytes
Desc: not available
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20110205/af695df0/attachment-0001.bin>


More information about the TYPO3-team-core mailing list