Bug #17002

cHash is not recreated on disposal in config.linkVars

Added by Oliver Hader over 12 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2007-02-17
Due date:
% Done:

0%

TYPO3 Version:
4.1
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

Imagine you'd like to forward one or more extension variables through the system. The common way to do this is to use config.linkVars. For caching purposes the cHash should be set.

Example:
config.linkVars = type,L,tx_myext_pi1,tx_myext_pi2,cHash

Unfortunatelly the cHash will be taken as it is from the current page being displayed. A wrong cHash results into an error message being reported ("wrong cHash").

The solution is to recreate/recalculate the cHash if it should be used in config.linkVars.

(issue imported from #M5010)

0005010.patch View (3.59 KB) Administrator Admin, 2007-02-17 11:16

0005010_2.patch View (4.72 KB) Administrator Admin, 2007-02-17 14:47

0005010_3.patch View (4.05 KB) Administrator Admin, 2007-02-19 11:07


Related issues

Related to TYPO3 Core - Bug #16953: RC1: Request parameters could not be validated Closed 2007-02-08
Related to TYPO3 Core - Bug #17115: Wrong &chash values should trigger an error Closed 2007-03-12
Related to TYPO3 Core - Feature #17238: Test config.linkVars - enable (basic) check for arrays Closed 2007-04-24
Related to TYPO3 Core - Bug #17095: Typolink : cHash isn't created if there's no additionalParams Closed 2007-03-08
Related to TYPO3 Core - Bug #19384: wrong cHash with additonalParams.wrap Closed 2008-09-28
Related to TYPO3 Core - Bug #19003: double cache or no cache through cHash variants of the same URL Closed 2008-06-23
Duplicated by TYPO3 Core - Bug #17070: typolink: cHash corrupted due to linkVars Closed 2007-03-02

History

#1 Updated by Oliver Hader over 12 years ago

The attached file 0005010.patch solves this problem.
  • t3lib/class.t3lib_tstemplate.php: Just removing redundancy, no functional change => cleaner
  • typo3/sysext/cms/tslib/class.tslib_pagegen.php: Recreation of cHash if necessary
  • typo3/sysext/cms/tslib/class.tslib_content.php: Change order of addQueryParams and linkVars (addQueryParams is more specific than linkVars)

#2 Updated by Michael Stucki over 12 years ago

Hi Oliver,

good idea! This adds a very useful functionality to make all links "safe" :-)

Some comments:

1. While looking at your patch I noticed that $val is actually holding keys, so it should be renamed here:
- foreach ($linkVarArr as $val) {
+ foreach ($linkVarArr as $key) {

2. We can discuss about this one :-)
- $GLOBALS['TSFE']->linkVars.= $value;
+ $GLOBALS['TSFE']->linkVars .= $value;

3. When recreating the cHash, you have this line:
+ if ($GLOBALS['TSFE']->linkVars && $createCHash) {

I suggest that you always first check for local variables before accessing other classes. It may be a speed gain of just 0.001ms, but since we have such situations quite often, it may add a lot of overtime in total.

But all in all I like this change! Didn't test it yet, though...

#3 Updated by Oliver Hader over 12 years ago

I agree. I'll change the this you mentioned and provide a new patch.

#4 Updated by Oliver Hader over 12 years ago

I changed some thing in 0005010_2.patch:
  • renamed $val to $var and $tmpVal to $tmpVar (it is a variable of linkVars and thus not a value or a key, is it?)
  • Reduced direct writing and reading to $GLOBALS['TSFE']->linkVars

#5 Updated by Popy no-lastname-given over 12 years ago

cHash should not be in linkVars list ! It needs to be generated for each link !

#6 Updated by Oliver Hader over 12 years ago

@Popy: Guess what this patch is doing! ;-)

#7 Updated by Ralf Hettinger over 12 years ago

0005010_3.patch does work for me (several linkVars - single and array GET vars applied) like a charm and avoids serious performance issues that resulted in non cached pages with linkVars before.

Thank you very much!

If you consider this patch to merge, could you have a look at #17238 please? The topic is not really the same but the same lines of code are affected - so it might be reasonable to do so.

#8 Updated by Sareen Millet over 12 years ago

This really does solve a lot of problems. But if using RealUrl with the setting for variable bypass like this:

'1' => array (
'GETvar' => 'L',
'valueMap' => array (
#'en'=>'0',
'de' => '1',
'fr' => '2',
),
'noMatch' => 'bypass',
#'valueDefault' => 'en',
),

it still won't work propably.
Cause &L=0 will create a different cHash than no 'L' Parameter at all.

#9 Updated by Michael Stucki about 12 years ago

Please consider this: http://lists.netfielders.de/pipermail/typo3-dev/2007-August/024671.html

I'm not sure anymore if this feature is really useful. If you implement this, then the caching routine needs to be improved. I have currently no idea how this should work without introducing a separate GET parameters for cache and check hash...

- michael

#10 Updated by Sareen Millet about 12 years ago

Hi,

is there any reason why the change from patch 0005161 is not incuded in this patch even if it affects the same lines?

File class.tslib_content.php, line 5221 :
[code]
} elseif ($conf['useCacheHash']) {
[/code]

change to:
[code]
}
if ($conf['useCacheHash'] && trim($GLOBALS['TSFE']->linkVars.$addQueryParams)) {
[/code]

This change makes a lot of sense for me. As it enables the use of cHash even when $addQueryParams are empty and $GLOBALS['TSFE']->linkVars is set. This is very usefull if for e.G. if a typoLink changes a linkVar like "L". So it will include the new "L"-Value in the addQueryParams. So both, the $GLOBALS['TSFE']->linkVars and the $addQueryParams should be checked for the cHash.

Are there any misconceptions in my point of view?

greetings

Sareen

#11 Updated by Oliver Hader over 11 years ago

Yes, the reason is that this bug report existed before bug #17120 and that they address different problems.

#12 Updated by Ronald Steiner about 11 years ago

Is this bug still present in Typo3 4.2.1?
I experience same behaviour, but the patch seems not to work there.
Any ideas?

#13 Updated by Ronald Steiner about 11 years ago

The Sponsorship is when the bug is fixed in the core.

#14 Updated by Ronald Steiner about 11 years ago

I want to point out some additional issues with cHash and caching that are closely related to this issue:

1)
After changing the L parameter the cHash of the previous L parameter is taken. The cHash after the language switch therefore is wrong. The page with the wrong cHash therefore is not cached. – this is just as it is explained in this bug 0005010
If RealURL is used the same phenomena occurs even if cHash is not visable in the URL

2)
These two links point to the same page:
(a) http://localhost/t3421/index.php?id=6&L=1
(b) http://localhost/t3421/index.php?id=6&L=1&cHash=b5e9312461
(a) is generated by the menu, (b) is generated by:
[code]
typolink.parameter.data = page:uid
typolink.additionalParams = &L=1
typolink.addQueryString = 1
typolink.addQueryString.exclude = L,id,cHash,no_cache
typolink.addQueryString.method = GET
typolink.useCacheHash = 1
typolink.no_cache = 0
[/code]
“useCacheHash” is necessary, cause addQueryString = 1 might carry additional params.
Result: Both URL addresses lead to two identical pages in the cache.
If RealURL is used the problem obviously is solved. Only one URL is generated and only one page is in the cache.

3)
If we have same scenario just with L=0 param the result is three URL addresses fort he same page:
(a) http://localhost/t3421/index.php?id=6
(b) http://localhost/t3421/index.php?id=6&L=0
(c) http://localhost/t3421/index.php?id=6&L=0&cHash=7fc4118ac9
Just as 2) version (a) and (b) are cached separately to version (c). So again there are two identical pages in the cache.
But this time the problem is not solved by installing RealURL. Only one URL is generated, but the cache is not cached at all.

#15 Updated by Ronald Steiner about 11 years ago

I just reported this as a seperate bug #19003 as it might be a independent problem

#16 Updated by Popy no-lastname-given about 11 years ago

Your first point (about wrong chash with L parameter) is related to bug #17070

#17 Updated by Ronald Steiner about 11 years ago

I kow, the entire bug 0005110 is related to bug 0005117
There are quite some bugs about cHash and Caching around.

#18 Updated by Alexander Opitz over 6 years ago

  • Category deleted (Communication)
  • Status changed from Accepted to Needs Feedback
  • Target version deleted (0)

The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?

#19 Updated by Alexander Opitz about 6 years ago

  • Status changed from Needs Feedback to Closed
  • Assignee deleted (Oliver Hader)

No feedback for over 90 days.

Also available in: Atom PDF