Bug #17115

Wrong &chash values should trigger an error

Added by Michael Stucki almost 13 years ago. Updated about 1 year ago.

Status:
Closed
Priority:
Should have
Category:
Frontend
Target version:
-
Start date:
2007-03-12
Due date:
% Done:

0%

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

Description

TYPO3 uses a parameter "&cHash" to cache different views of the same page (e.g. a plugin containing a record browser).

If the &cHash parameter is wrong, someone has most likely modified a link generated by TYPO3 manually.

The behaviour for such a case can be changed through $TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError']. Up to TYPO3 4.1, this is set to false which means that no error is triggered, but caching will be disabled for that page.

This is a new attempt for fixing a known problem. The fix was in TYPO3 between 4.1beta2 and 4.1RC2, but was reverted recently before 4.1 final.

The reason for reverting it was that many buggy extensions have always worked fine even though the chash value was wrong. They just had no_cache enabled, so most likeley nobody noticed.

By reintroducing the patch for TYPO3 4.2 I want to give extension authors several months time to fix their eventually broken extensions.
(issue imported from #M5209)

bug_5209.diff View (3.33 KB) Administrator Admin, 2007-03-12 23:51


Related issues

Related to TYPO3 Core - Bug #16953: RC1: Request parameters could not be validated Closed 2007-02-08
Related to TYPO3 Core - Bug #17002: cHash is not recreated on disposal in config.linkVars Closed 2007-02-17
Related to TYPO3 Core - Feature #17862: Make excludeCHashVars work Closed 2007-11-29

History

#1 Updated by Oliver Hader almost 13 years ago

I think most "buggy extensions" were built as hyrid, using caching/cHash by default and disabling the cache in special situations by calling $TSFE->no_cache(). This could happen for e.g. guestbooks or shopping systems - the regular content for viewing should be cached - dynamic interactions with the user (e.g. put an article to a cart) should not.

Furthermore it might happen, that two different extensions are located on a page. The first is of type USER (cached) and the second is of type USER_INT (uncached). Providing data for both of them in one link will also be an issue for the cHash.

Thus, it might me required to have a method to walk around the cHash checks by using a so-called cHashTunnel. Parameters using this tunnel are not checked against being represented by the given cHash - but could of cause have an own cache for their specific demand.

#2 Updated by Steffen Kamper almost 13 years ago

As we discussed in ECT-list, there are some combinations in extensions that causes this error (e.g. USER_INT and $GLOBALS['TSFE']->reqCHash();). So it is very important to make a strict guideline for extensions, how they should handle the cHash.

The most errors occures with developers when not knowing how to set the no_cache, how $pi_checkCHash influences the links etc.

If you want to set the 'pageNotFoundOnCHashError' default to 1, a list has to be made for the extensions that doesn't work with this, the authors should be contacted to update the extensions.

#3 Updated by Michael Stucki over 12 years ago

Hi Steffen,

I've seen that Elmar has set up an article about proper caching of plugins, so probably you could manage to put this into the articles section on TYPO3.org? (Probably it can easily be merged with the "mysteries of chash"?)

Also I like the idea of having a list with extensions that require to be changed accordingly. We will definitely need to push this, therefore I find it important that it gets back into Trunk (4.2) as soon as possible...

- michael

#4 Updated by Alexander Opitz over 6 years ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (0)
  • TYPO3 Version set to 4.1

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

#5 Updated by Uwe Trotzek over 6 years ago

Since TYPO3 6.1.X the default value of pageNotFoundOnCHashError has been set to '1'. As we used the default value of this option we didn't notice the problem before.

We get this error with ppw_lunchmenu's pdf generation. Of course an old extension but I think there are more Exts with the same error.

So I would say: Yes, the problem still exists.

#6 Updated by Alexander Opitz over 6 years ago

  • Status changed from Needs Feedback to New

#7 Updated by Mathias Schreiber almost 5 years ago

  • Category set to Frontend
  • Status changed from New to Needs Feedback
  • Assignee changed from Michael Stucki to Mathias Schreiber
  • Is Regression set to No

Is this still an issue?

#8 Updated by Georg Ringer almost 5 years ago

imo this has been resolved by turning it on by default!

#9 Updated by Michael Stucki over 4 years ago

  • Status changed from Needs Feedback to Resolved

Uwe Trotzek wrote:

Since TYPO3 6.1.X the default value of pageNotFoundOnCHashError has been set to '1'. As we used the default value of this option we didn't notice the problem before.

We get this error with ppw_lunchmenu's pdf generation. Of course an old extension but I think there are more Exts with the same error.

So I would say: Yes, the problem still exists.

What you are describing sounds like expected: the cHash is wrong and therefore an error is shown. In that case, the real problem is in your extension "ppw_lunchmenu" and needs to be fixed. It was only not noticed before the mentioned change.

@all: I consider the issue as solved now that pageNotFoundOnCHashError is TRUE by default.

#10 Updated by Benni Mack about 1 year ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF