Project

General

Profile

Actions

Bug #21345

closed

cHash is generated when no parameters are given

Added by Michael Birchler about 15 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Should have
Category:
Caching
Target version:
-
Start date:
2009-10-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

If somebody adds accidentally useCacheHash to typolink configuration the caching of Typo3 gets broken (only in combination with RealURL).

Example Typoscript :
10 = TEXT
10 {
typolink {
parameter.data = TSFE:id
additionalParams.dataWrap = &{getIndpEnv : QUERY_STRING}
useCacheHash = 1
}
}

If getIndpEnv : QUERY_STRING is empty the value of additionalParams is '&'

The typolink method of tslib_content calculates always the cHash if useCacheHash is set in typolinkconfig.

If additionalParams is '&' t3lib_div::cHashParams returns an array with two items:
'encryptionKey' => 'encrypt key
'' => empty

so the cHash gets calculated faulty and RealURL takes the faulty cHash and stores it to the tx_realurl_chashcache table.

The result is faulty cHash calculations:
The incoming cHash "f2810e4376" and calculated cHash "5de407b1c4" did not match, so caching was disabled. The fieldlist used was "encryptionKey"
and the site runs on non cached.

The attached patch pervents faulty calculations.

(issue imported from #M12322)


Files

class.tslib_content.diff (2.17 KB) class.tslib_content.diff Administrator Admin, 2009-10-23 11:45
bug_12322.diff (1.58 KB) bug_12322.diff Administrator Admin, 2009-10-23 14:36
bug_12322_class.t3lib_div.diff (1 KB) bug_12322_class.t3lib_div.diff Administrator Admin, 2009-10-28 11:10
12322.diff (1 KB) 12322.diff Administrator Admin, 2010-07-13 13:23
Actions #1

Updated by Steffen Müller about 15 years ago

cHash calculation is fine, but your Typoscript example has the bug. You should check in TS if QUERY_STRING is empty.

Actions #2

Updated by Michael Birchler about 15 years ago

Yes sure it's a bug in the example Typoscript the correct way would be to write it this way:
additionalParams = &{getIndpEnv : QUERY_STRING}
additionalParams {
insertData = 1
if.isTrue.data = getIndpEnv : QUERY_STRING
}

The patch just prevents the possible error in Typoscript.

Actions #3

Updated by Michael Birchler about 15 years ago

bug_12322.diff is the correct patch

Actions #4

Updated by Steffen Müller about 15 years ago

One cannot prevent all possible misconfigurations in typoscript. So your patch just blows up the core without gaining much effect.
Since we agree it is a misconfiguration in Typoscript, I plead for closing this bug.

Actions #5

Updated by Michael Birchler about 15 years ago

I think such typoscript errors exists on many sites. If you have such an error on a big site is hard to locate it. The only hint is "the incoming cHash "xxxx" and calculated cHash "xxx" did not match" in the admin panel.

For me it's not a blow up but rather a small improvement that prevents possible caching problems with RealURL.

Actions #6

Updated by Michael Birchler about 15 years ago

An other problem occurs if you have the following typoscript setup:
10 = TEXT
10 {
typolink {
parameter.data = TSFE:id
additionalParams.dataWrap = &tx_testext_pi1[showUid]={field:uid}

}
}

If uid is empty t3lib_div::cHashParams returns a array with an empty value. And the cHash does not match again.

Actions #7

Updated by Steffen Müller about 15 years ago

Nobody prevents you from sending an RFC to the core list and try to get it into the core:
http://typo3.org/teams/core/core-mailinglist-rules/

Actions #8

Updated by Dmitry Dulepov over 14 years ago

I confirm the problem. I just found identical cHashes coming from the empty parameter string. They spoil RealURL cache.

Actions #9

Updated by Dmitry Dulepov over 14 years ago

rev 8187, 8188, 8189

Actions

Also available in: Atom PDF