Bug #88136

requireCHashArgumentForActionArguments may cause 404 errors

Added by Dmitry Dulepov 10 days ago. Updated 9 days ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2019-04-11
Due date:
% Done:

0%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
easy
Is Regression:
Sprint Focus:

Description

After the introduction of routing in TYPO3 9.5 there is a major issue with requireCHashArgumentForActionArguments: if enabled, it causes a page not found error for all configured routes without non-routed parameters.

Here is why it happens.

URLs are generated by `\TYPO3\CMS\Core\Routing\PageRouter::generateUri()` method. This method will unconditionally remove cHash generated by typolink:

 238       // cHash is never considered because cHash is built by this very method.
 239       unset($originalParameters['cHash']);

Later the function checks if it needs to add cHash:

305        if ($matchedRoute && $pageRouteResult && !empty($pageRouteResult->getDynamicArguments())) {
306            $cacheHash = $this->generateCacheHash($pageId, $pageRouteResult);
307
308            if (!empty($cacheHash)) {
309                $queryArguments = $pageRouteResult->getQueryArguments();
310                $queryArguments['cHash'] = $cacheHash;
311                $uri = $uri->withQuery(http_build_query($queryArguments, '', '&', PHP_QUERY_RFC3986));
312            }
313        }

Those "dynamic arguments" are arguments that are not mapped by any routes. Thus there will be no cHash in the url if all parameters are mapped by routing! Thus if all parameters are mapped by routing and requireCHashArgumentForActionArguments = 1, there will be a page not found error.

Additional information.

Earlier cHash was always required for proper caching if there are url parameters (see https://typo3.org/article/the-mysteries-of-chash/). Now, after recent change, it is no longer needed because TyposcriptFrontendController uses routing parameters for cache:

    protected function createHashBase($createLockHashBase = false)
    {
...
        $hashParameters = [
...
            // cHash_array includes dynamic route arguments (if route was resolved)
            'cHash' => $this->cHash_array,
            // additional variation trigger for static routes
            'staticRouteArguments' => $this->pageArguments !== null ? $this->pageArguments->getStaticArguments() : null,
            'domainStartPage' => $this->domainStartPage
        ];
...
    }

So having requireCHashArgumentForActionArguments does not make any sense now because with proper routing config this setting will not work.


Related issues

Related to TYPO3 Core - Bug #87653: cHash error with extbase plugin and routeEnhancer Closed 2019-02-05

History

#1 Updated by Dmitry Dulepov 10 days ago

  • Related to Bug #87653: cHash error with extbase plugin and routeEnhancer added

#2 Updated by Oliver Hader 10 days ago

Thanks for the report. The references issue mentions config.defaultGetVars, is that defined in your scenario as well?

Could you please share the URLs you're using for
  • URL generation (e.g. input id=123&tx_plugin_pi1[abc]=234)
  • URL resolving (e.g. /page/plugin/abc-value)

Having according scenarios and examples would allow to create (additional) test cases. Thanks in advance!

#3 Updated by Dmitry Dulepov 10 days ago

Yes, I independently found that `config.defaultGetVars.L = 0` was set. Even though `L` does not affect cHash, it causes $TSFE->reqCHash to proceed because `L` appears in page's dynamic arguments. That must be the cause of 404s.

So this needs more investigation and correction of the original text.

#4 Updated by Dmitry Dulepov 10 days ago

  • Subject changed from Remove requireCHashArgumentForActionArguments setting to requireCHashArgumentForActionArguments may cause 404 errors

#5 Updated by Oliver Hader 9 days ago

Thanks Dmitry, that's good information and narrows down analysis on this behavior. I could try to integrate that scenario to our tests as well...

Also available in: Atom PDF