Bug #88688
closedrouteEnhancer: cHash validation errors are cached and subseqently show up on correct URLs, too (and vice versa)
0%
Description
Here is my current setup:
Extbase-routeEnhancer (default news detail):
Blogposts: type: Extbase limitToPages: [292] extension: News plugin: Pi1 routes: - { routePath: '/{news_title}', _controller: 'News::detail', _arguments: {'news_title': 'news'} } aspects: news_title: type: PersistedAliasMapper tableName: 'tx_news_domain_model_news' routeFieldName: 'path_segment'
1) clear cache
2) /base/someArticle?lala=1 -> cHash validation failed (as expected)
3) /base/someArticle -> cHash validation failed
4) clear cache
5) /base/someArticle -> OK (as expected)
6) /base/someArticle?lala=1 -> OK (should throw cHash error)
So basically the first call of the plugin gets cached. Any subsequent call will reproduce the same result (which is ok for most parameters, but not for the cHash validation itself!)
This affects 9.5 and master.
It is not reproducible for plain (non-enhancer) plugin URLs.
I discovered it when reviewing this bug some weeks ago:
https://review.typo3.org/c/Packages/TYPO3.CMS/+/60296 (cHash calculation respects excludedParameters for enhancers)
But it was out of scope there and I forgot to submit a bug report. Now I experienced it on a live v9 site.
Updated by Jonas Eberle over 5 years ago
- Subject changed from routeEnhancer: cHash validation errors are cached and subseqently show up on correct URLs, too to routeEnhancer: cHash validation errors are cached and subseqently show up on correct URLs, too (and vice versa)
Updated by Susanne Moog about 5 years ago
- Sprint Focus set to On Location Sprint
Updated by Oliver Hader almost 5 years ago
- Related to Bug #78068: Page get cached when called without cHash-param added
Updated by Philipp Kitzberger 6 months ago
This is still an issue for (at least) 11!
Updated by Philipp Kitzberger 6 months ago
Further research lead to #95297 which introduced a new setting to v10+
$GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']
When enabled, the same validation for calculating a "cHash" value is used as when a valid or invalid "cHash" parameter is given to a request, even when no "cHash" is given.
See its changelog entry: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/10.4.x/Important-95297-StrictCHashValidationFeatureFlag.html
So it's either setting enforceValidation
or defining the GEt parameters namespaces as requireCacheHashPresenceParameters
I couldn't reproduce the faulty behaviour anymore using either option, so I guess this issue can be closed now.
Updated by Jonas Eberle 6 months ago
- Status changed from New to Resolved
I can confirm. I tested in 12.4 and 13.2-dev.
With $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']=true
, additional parameters lead to 404.
With $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['enforceValidation']=false
, page is rendered normally and the canonical does not include the parameter (and it is rendered from the cache without the parameter). In my opinion that would be the even better default because we would not have to configure $GLOBALS['TYPO3_CONF_VARS']['FE']['cacheHash']['excludedParameters']
. TYPO3 would just be compatible with any parameters coming from the outside world that are possibly consumed by some on-page JavaScript (like Analytics or an app that does some on-page routing for sharable URLs with parameters).
In both cases caching does not affect it any more. So this bug is fixed.