TYPO3 Core

Dear Helmut,
If I send params including a proper cHash value by a POST form, TYPO3 throws this error:

Page Not Found
Reason: Request parameters could not be validated (&cHash empty)

If I move the form method from POST to GET the TYPO3 cHash comparison is proper.

It seems, that there is a bug in the code of the TypoScriptFrontendController class (see above).
The code evaluates GET params only.

• with form method GET
• and with form method POST

I would be happy, if my report is clear :)

Thanks for your quick response.

Dirk

Is it possible for you to show us a minimal code sample (controller/view/special TS configuration/...) on how to reproduce the problem?

• http://forum.typo3.org/index.php?t=rview&goto=719319#msg_719319

Does it mean, I must send a form with the method GET and method POST is unpossible, because cHash comparison failed?
And if yes, would it be nice, to add a tip to the error message of the TypoScriptFrontendController class like

Page Not Found
Reason: Request parameters could not be validated (&cHash empty)
Be aware: Parameters must be send by the form method GET

Kind regards
Dirk

You have the form-tag auto-generated by Extbase I guess? Or do you generate that yourself?

Dear Helmut, dear Xaviar,
this is a code snippet for rreproducing the problem:

Form with method GET works proper:

  <form name="form_confirm" method="GET">
    <fieldset>
      <legend>
        Start the Installation
      </legend>
      <input type="hidden" name="tx_orginstaller_pi1[confirm]" value="1" />
      <input type="hidden" name="cHash"                        value="5416c8c16f8ea7d9823472d0ff373d39" />
      <input type="submit" name="submit" value=" Install it! " />
    </fieldset>
  </form>

Form with method POST throws the error "...could not be validated (&cHash empty)" from above:

  <form name="form_confirm" method="POST">
    <fieldset>
      <legend>
        Start the Installation
      </legend>
      <input type="hidden" name="tx_orginstaller_pi1[confirm]" value="1" />
      <input type="hidden" name="cHash"                        value="5416c8c16f8ea7d9823472d0ff373d39" />
      <input type="submit" name="submit" value=" Install it! " />
    </fieldset>
  </form>

The cHash value is calculated in both samples (GET and POST):

  $cacheHash = t3lib_div::makeInstance('t3lib_cacheHash');
  $cHash     = $cacheHash->generateForParameters('&tx_orginstaller_pi1[confirm]=1&submit= Install it! ');

Kind regards
Dirk

Be ware, the generated cHash value depends on the encryption key of your TYPO3 installation.
If you like to reproduce the error, you have to generate your cHash value first an replace my given value with yours.

• POST action should not get cached since POST means a change is going on, do you experience a problem if you don't have a cHash?
• cHash is meant to validate the parameters and prevent caching problems, thus when using a GET request

As such there should be no need to provide a cHash with POST requests and as you see it makes no sense to validate POST parameters.

And do not forget that best practices redirect (as GET) to some "confirmation page" or alike and do not output HTML response right away when doing a POST request.

For the form you mentioned: I guess for now you'd need to put the cHash into the URL (as part of the "action") for it to be recognised, instead of sending it as part of the POST.

I agree that using POST and caching is usually a strange combination. Should we maybe consider avoiding to cache POST-requests? Or give a warning of some sort if some plugin tries to use POST with something that involves caching? Maybe that helps more than complaining about a wrong/missing cHash in that case.

Stefan Neufeind wrote:

For the form you mentioned: I guess for now you'd need to put the cHash into the URL (as part of the "action") for it to be recognised, instead of sending it as part of the POST.

Yeah, but only, if you have get vars in your action url. If you send by POST without getvars in the url, simple remove the cHash!

I agree that using POST and caching is usually a strange combination. Should we maybe consider avoiding to cache POST-requests?

In general? Why that? Should be enough to be aware of not caching the content the POST is sent for.

I agree that using POST and caching is usually a strange combination.

I agree too.

1. $TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError'] is true by default.
2. typo3_src-6.2.4/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php::makeCacheHash doesn't respect the no_cache parameter, if pageNotFoundOnCHashError is true
3. Effect is, you can't use a POST form without any caching but you disable pageNotFoundOnCHashError.

Code snippet from TypoScriptFrontendController.php::makeCacheHash

    public function makeCacheHash() {
        // No need to test anything if caching was already disabled.
        if ($this->no_cache && !$this->TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError']) {
            return;
        }

• pageNotFoundOnCHashError = true
• A POST form without any caching

Why it isn't possible?
Or do I have a knot in my brain?

If a request should not cached in case of the POST method, would be this a possible improvement
in typo3_src-6.2.4/typo3/sysext/frontend/Classes/Controller/TypoScriptFrontendController.php::makeCacheHash?

Current code:

    public function makeCacheHash() {
        // No need to test anything if caching was already disabled.
        if ($this->no_cache && !$this->TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError']) {
            return;
        }
        ...

Improved code:

    public function makeCacheHash() {
        // #61664, 140917, dwildt, 5+
        // No need to test anything if params are sent by POST method.
        $POST = GeneralUtility::_POST();
        if (is_array($POST)) {
            return;      
                }
        // No need to test anything if caching was already disabled.
        if ($this->no_cache && !$this->TYPO3_CONF_VARS['FE']['pageNotFoundOnCHashError']) {
            return;
        }
        ...

One additional note here:

If you have question on the topics cHash or USER_INT, feel free to ask on the dev list.

Dear Helmut,
Thanks a lot for your engagement.

Kind regards
Dirk

Had the same issue. Setting the plugin, the whole page or whatever to non-cached didn't help as well. I wonder if CoolUri might be part of the problem here in my installation. But if you look up the internal URL, there is just the id=... in the URL here. I wonder if the additional POST-data make any difference or not.

Workaround: Disable "pageNotFoundOnCacheHasherror" sigh

same issue here.
i had to Disable "pageNotFoundOnCacheHasherror" .

How can we use fluid forms (which are generated with method="post") which act as a filter form
without disabling pageNotFoundOnCacheHasherror ?

f.e.:

form in searchAction makes a post to listAction
should listAction be listed in the list "non-cacheable actions" in ext_localconf.php ?
Could this be an issue?

I have this issue with tt_news when using the search. Many others, too, I've found more than 600 results in google.

I do not understand the problem with cHash here:
I have a news search on a cached page, e.g.: news/search.html
Now, I execute the search, so this cached page is called again (the url stays exactly the same!), with POST vars.
The tt_news plugin is USER_INT, so it should display the search results. But after submitting the search form I get this "cHash comparison failed" error.