Bug #17070: typolink: cHash corrupted due to linkVars - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #17070

closed

typolink: cHash corrupted due to linkVars

Added by Popy no-lastname-given about 17 years ago. Updated over 13 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Dmitry Dulepov

Category:

Communication

Target version:

Start date:

2007-03-02

Due date:

% Done:

Estimated time:

TYPO3 Version:

4.0

PHP Version:

4.3

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

I've found an error in function typolink of class.tslib_content.php

Line 5222 :
$pA = t3lib_div::cHashParams($addQueryParams.$GLOBALS['TSFE']->linkVars);

Here linkvars are appended to additionalParams, wich is wrong, because when the url is build (in class.tstemplate.php, function linkData, line 1382), linkVars are prepended (that allows additionalParams to ovveride linkVars).

Also when a typolink tries to override a linkVar, the cHash is always wrong!
Example : overriding L parameter from value 1 to value 2 :
cHash is calculated for &L=2&L=1, but the final link will be &L=1&L=2

Also I propose to replace the line 5222 (in class.tslib_content.php)
$pA=t3lib_div::cHashParams($addQueryParams.$GLOBALS['TSFE']->linkVars);

by this :
$pA=t3lib_div::cHashParams($GLOBALS['TSFE']->linkVars.$addQueryParams);

cHash is not calculated by menus (HMENU cObjects), and putting cHash value in linkVars is not a good solution because cHash will not be valid if current url contains a parameter wich will not be saved by linkVars

Maybe cHash should be generated in the function linkData? Or menu should use typolink instead of linkdata?
(issue imported from #M5117)

Files

Download all files

0005117.patch (1.36 KB) 0005117.patch		Administrator Admin, 2007-03-04 13:12
tslib_content.diff (2.21 KB) tslib_content.diff		Administrator Admin, 2007-08-02 15:20
tslib_content.trunk.patch (1.18 KB) tslib_content.trunk.patch		Administrator Admin, 2010-05-20 15:41
tslib_content.v43.patch (1.18 KB) tslib_content.v43.patch		Administrator Admin, 2010-05-20 15:42
tslib_content.v42.patch (1.58 KB) tslib_content.v42.patch		Administrator Admin, 2010-05-20 15:42
tslib_content.v42.fixed.patch (1.89 KB) tslib_content.v42.fixed.patch		Administrator Admin, 2010-05-21 10:37
5117_4-4.diff (1.39 KB) 5117_4-4.diff		Administrator Admin, 2010-06-02 14:25

Related issues 4 (0 open — 4 closed)

Actions

Copy link

Updated by Oliver Hader about 17 years ago

I can confirm this and agree that linkVars and additionalParams have to be swapped. My patch concerning cHash in linkVars at bug-id #17002 does the same.
This behaviour also exists in TYPO3 4.1RC2.

Actions

Copy link

Updated by Popy no-lastname-given about 17 years ago

Not really the same : I need the cHash to be correctly generated by typolink. in some cases Links should not contain a cHash, that's why cHash should not be automatically created.

The error is still present in 4.1RC2.

Actions

Copy link

Updated by Oliver Hader about 17 years ago

Sorry, I tried to say "covers/contains the same problem in class.tslib_content.php". I attached a file which changes the order of linkVars and additionalParams.

Actions

Copy link

Updated by Sareen Millet almost 17 years ago

This Patch really seams to solve the above Problem. But if you set $TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError'] = 1 you will notice that after overriding L parameter from value 1 to value 0 the generated cHash is still wrong.

Actions

Copy link

Updated by Popy no-lastname-given almost 17 years ago

This is another problem : see related bug #17095

Actions

Copy link

Updated by Michael Stucki almost 17 years ago

This is not really a duplicate, but exactly this fix is already contained in Olivers patch in #17002. So I assume it will be fixed shortly.

Actions

Copy link

Updated by Popy no-lastname-given over 16 years ago

Bug still present in typo3 v 4.1.2 (and #17095 too !)

Actions

Copy link

Updated by Popy no-lastname-given about 14 years ago

Reminder : Bug still present in latests releases (v4.1, 4.2, 4.3).

I can build new pacth file if needed and if it has a chance to be taken in account.

Actions

Copy link

Updated by Chris topher almost 14 years ago

@ Popy: A solution to the problem surely should be integrated!
It would be great, if you could update the patch!
Please post it to Core List afterwards. See http://typo3.org/teams/core/core-mailinglist-rules/

Actions

Copy link

#10

Updated by Popy no-lastname-given almost 14 years ago

patch updated for trunk version and 4.3 + 4.2 versions

Actions

Copy link

#11

Updated by Andreas Kiessling almost 14 years ago

I guess 4.2 won't work. There is no function "generateCHash" in t3lib_div?

Actions

Copy link

#12

Updated by Popy no-lastname-given almost 14 years ago

Popy failed at "Copy paste"

New patch

Actions

Copy link

#13

Updated by mitja doma almost 14 years ago

I can confirm this bug also in typo3core svn trunk (rev 7129).

In my case it resulted in a huge realurl encodecache table where identical urls (e.g. id=2&L=3) had many different (up to 10) cHash values - all stored in the encode cache table.

applying the patch seems to have solved this bit,
there are no more 'duplicate' cHashes in the encode cache table anymore.

Actions

Copy link

#14