Bug #17115
closed
Wrong &chash values should trigger an error
Added by Michael Stucki about 17 years ago.
Updated over 5 years ago.
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)
Files
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.
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.
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
- 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)?
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.
- Status changed from Needs Feedback to New
- Category set to Frontend
- Status changed from New to Needs Feedback
- Assignee changed from Michael Stucki to Mathias Schreiber
- Is Regression set to No
imo this has been resolved by turning it on by default!
- 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 review: I consider the issue as solved now that pageNotFoundOnCHashError is TRUE by default.
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by