TYPO3 Core

The reason comes from file tslib/class.tslib_fe.php. Somehow a cHash evaluation error occures. But all the caches have been deleted.

function reqCHash() {
if (!$this->cHash) {
if ($this->TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError']) {
if ($this->tempContent) { $this->clearPageCacheContent(); }
$this->pageNotFoundAndExit('Request parameters could not be validated (&cHash empty)');
} else {
$this->set_no_cache();
$GLOBALS['TT']->setTSlogMessage('TSFE->reqCHash(): No &cHash parameter was sent for GET vars though required so caching is disabled ',2);
}
}
}

Solution:
delete the "if ($this->TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError']) {"
Then it works.

Hi Stucki,

any idea what this is caused by?

cheers
Ingmar

The reason relies on revision 1986 (see ChangeLog http://svn.t3.digitaldistrict.de/cgi-bin/trac.cgi/changeset/6707#file2)

TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError'] was set to true by default, so if the cHash is empty the error message is outputed.

IMO there is nothing against the forced implementation of cHash in extensions if an extension is written from scratch. If old extensions had been working for month and years, and with 4.1RC1 they won't - this is really a blocker.

So I tend to revert the pageNotFoundOnCHashError to "false" als default value. Or create new configuration keys pageNotFoundOnCHashEmpty.

Please see the attached patch 0004940.patch

• pageNotFoundOnCHashError stays true by default
• pageNotFoundOnCHashEmpty is introduced and is false by default

If cHash is set but is delivered false in the front-end it is an error. But if the cHash is missung due to an old extension, this is no error. But the admin is free to enable this setting TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashEmpty'].

What do you think?

Franz, this is not a bug!

The error you are posting here is written in $TSFE->reqCHash(). However, $TSFE->reqCHash() is only called if a plugin has been called with at least one &pi_*-attribute (see class.tslib_pibase.php, line 212).

So how could this error appear right after you have clicked the "show" icon of the BE...?

This whole change was made to make website plugins more secure and assure that only server-generated links can be loaded. If any parameter of this plugin has been manually modified, the error you have seen will appear because the &cHash doesn't match anymore. So it will help you to protect your server from DOS attacks (by filling up the cache_* tables of the DB).

Consequently, adding a new property "pageNotFoundOnCHashEmpty" doesn't make much sense either because this would again allow to modify URL parameters.

If you are fine with that, then you as a site owner can simply turn off "pageNotFoundOnCHashError", but I strongly believe that we do this by default (again)!

By the way, $TSFE->reqCHash() has one more condition for being called: The plugin must have $this->pi_checkCHash set true, however, by default it is always false. (It's recommended to enable it for USER objects, though).

Finally: If an extension author writes a USER plugins but wants to call $cObj->typolink() directly, then he should always make sure to turn on the "useCacheHash" property when calling it. Otherwise that would again make the whole thingy pretty ineffective...

The issue can be closed, this is not a bug, it's part of a feature. If you want to allow it, you can do that on your own, but the default will be to secure a site.

- michael

This error occurs only because of TYPO3 upgrade to 4.1RC. This is against upwards compatibility. Therefore this must be fixed or many persons will run into difficulties. I can make changes only in later versions of the extensions.

The URL is a tt_products BASKET plugin, which does not use any caches. The FE caching has been turned off.
http://localhost/index.php?id=36
When I enable those lines and reload I run into this error message and everything is blocked.

Wanted new feature:
When a backend user is logged in then there should not be such a check. Testing would be easier then.
And the FE cache has been cleared. When the FE cache is empty then no error message should be shown but the FE page should be created.

Initially I thought the same about this issue, but security has priority over backwards compatibility at all. So after carfully checking the source code of the TYPO3 Core this concept is okay. If the error occurs it might be a bug in the extension.

Is this tt_product baset plugin available in the TER so we could check what happens. Or is it just the tt_content basket plugin (view/class.tx_ttproducts_basket_view.php)? And furthermore we could finally determine for sure if it is a core or extension bug?

Yes, tt_products is on TER. And it also does not work with the LIST plugin.

Ah, so you only checked this with tt_products so far?! I would have expected some more initiative from you, really.

Yesterday evening, Oliver and I spent 2 hours (both!) to investigate this problem, and finally conclude that there is nothing wrong with this behaviour. Why couldn't you at least check if any other extension besides tt_products is having the same problem?

If a current tt_products version breaks with 4.1, I really don't care for this. The change was an important security enhancement and therefore gets priority over compatibility. Because of this I had explicitely marked the change with three "!!!" in the ChangeLog, which indicates that this change may cause problems in some situations.
And since only tt_products seems to be affected, you should simply write an update for those people who use your extension.

- michael

There has been a line in pi1/class.tx_ttproducts_pi1.php which has been forgotten:

$GLOBALS['TSFE']->reqCHash();

It must be deleted there.

OK, there seems to be something we overlooked:

In case the basket is filled, you call $TSFE->set_no_cache() in pi1/class.tx_ttproducts_pi1.php on line 371.
After this, $TSFE->no_cache will be true while the plugin still indicates that it uses cHashes ($this->pi_checkCHash = TRUE).

So actually the plugin is misconfigured, but luckily we can easily work around that and prevent other extensions from having the same problem: Just check if $TSFE->no_cache is set and do not check the cHash in this case.

Attached is a patch that should fix the problem.

Thanks a lot Oliver for investigating this problem of Franz' extension...

- michael

Thanks.

But both changes in tt_products and tslib/class.tslib_fe.php still do not help in the case of a single item view. If you click to add a product into the basket you still run into this error message.

$this->no_cache = 0, because you are in the single view which is cached. From there you should come into the basket which would not be cached. However the basket page causes now this error message instead of being shown.

E.g. the single view is:
http://localhost/index.php?id=35&tx_ttproducts_pi1[backPID]=35&tx_ttproducts_pi1[product]=7&cHash=30bf4848ff
This page comes from the cache.
The destination from the FORM is: (button in den Warenkorb)
http://localhost/index.php?id=35&tx_ttproducts_pi1[backPID]=35&tx_ttproducts_pi1[product]=7
The destination page of the basket does not get shown.
Probably the cHash parameter must be added now even to the FORM url.

Hello Michael,

Finally: If an extension author writes a USER plugins but wants to call $cObj->typolink()
directly, then he should always make sure to turn on the "useCacheHash" property
when calling it.

It is hardly possible to set this "useCacheHash" property. This would mean I had to call the typo3Link function directly and not use any more the more easier special link functions like $this->pibase->cObj->getTypoLink_URL.

I would need an additional tslib_cObj element useCacheHash which overrides the $conf['useCacheHash']. The $conf['useCacheHash'] cannot be set with many functions.

Or the $conf should be a member variable to make it usable for all functions.

- Franz

-----------
function typoLink($linktxt, $conf) {
....
} elseif ($conf['useCacheHash']) { // cache hashing:
$pA = t3lib_div::cHashParams($addQueryParams.$GLOBALS['TSFE']->linkVars); // Added '.$this->linkVars' dec 2003: The need for adding the linkVars is that they will be included in the link, but not the cHash. Thus the linkVars will always be the problem that prevents the cHash from working. I cannot see what negative implications in terms of incompatibilities this could bring, but for now I hope there are none. So here we go... (- kasper)
$addQueryParams.= '&cHash='.t3lib_div::shortMD5(serialize($pA));
}
---------------------------

needed changes, because hardly any of those basic link functions can be used any more:

cObj:
function getTypoLink($label,$params,$urlParameters=array(),$target='',$conf=array()) {
function getTypoLink_URL($params,$urlParameters=array(),$target='',$conf=array()) {

pibase:
function pi_getPageLink($id,$target='',$urlParameters=array(),$conf=array())

Or a member variable.

I have uploaded these functions into fh_library 0.0.16. Just take it or tell me if there are any chances ...

A user encountered the same problem with my extension ab_linklist. Worked without any problems with T3 version < RC1.

Andreas: Can you reproduce the problem with your extension?

Yes, both on my development and my production system.

You can try yourself if you want - just click on the URL in one of the detailed link views:
http://www.tkdonline.de/linksammlung/

RealUrl makes it hard to debug this. Can you turn it off, please?

done.

This should already be fixed using the most recent patch. Can you please check?

works now - thanks!

I confirm this error while FE-Edit with cal.
After setting 'pageNotFoundOnCHashError' => 0 it works.

Hello Steffen,

please check also if this patch would help. Or inform the extension author to fix this, too.

- Franz

This breaks the daimi_event extension.
I hope this will be documented in the release notes for the next RC, so that extension authors have a chance to fix the extension. Also, I hope this will postpone Typo3 4.1 final to give time for extension authors to apply a fix.

For 4.1 final we have reverted to the old default value of pageNotFoundOnCHashError, so the problems should be gone in the final.

We'll have to get back to the issue during 4.2 development.

Reopening this entry, since the default value should still be changed for the upcoming version 4.2.

I just opened a new request #17115 to draw a line between this long thread. I tried to collect all necessary information in there...