1
votes

I'm using TYPO3 9.5 and building a search Extension with extbase and have some problems with the cHash.
I build my search form in fluid with f:form and use GET as method. There are no problems if I use POST.
My search action is configured as non-cachable action. I also tried to set the TypoScript config requireCHashArgumentForActionArguments = 0 for my extension. But every time I try to search, I get a 404. Even when I let the form viewhelper generate a cHash. The only workaround that is working, is to disable pageNotFoundOnCHashError in the LocalConfiguration. But that feels wrong to me.
The action works also if I create a Link with fixed search words.

So there are some questions that came up to me.

  • Why is a cHash for a non-cachable action needed?
  • How can the cHash work on a form at all? It's the concept of a form that the user can modify the values, and as far as I understand it is the concept of the chash to prevent this.

Here is also some example code

<f:form
  id="search-form"
  class="press-search-widget"
  additionalAttributes="{'role': 'search'}"
  method="get"
  action="search"
  extensionName="MySearch"
  pluginName="Mysearch"
  controller="Search"
  section="search-form" >

  <f:form.textfield
    id="pressfilter-search"
    class="form-control"
    type="text"
    name="searchTerms[searchTerm]"
    value="{parameters.searchTerm}"
    placeholder=""
  />

</f:form>
3

3 Answers

1
votes

Why is a cHash for a non-cachable action needed?

cHash is evaluated before it is known which TypoScript should be fetched, so it is also not known which (un-)cached plugins should be loaded or if they require cHash evaluation (or have it disabled).

How can the cHash work on a form at all? It's the concept of a form that the user can modify the values, and as far as I understand it is the concept of the chash to prevent this.

I don't know the reason of you using a form submission with HTTP GET. However all GET parameters are taken into account except for the ones excluded (see response above already).

I strongly recommend switching to HTTP POST - mainly because the HTTP standard requires POST parameters to not be cached (also not in the browser!), otherwise Visitor A could submit something with the form and Visitor B sees the result from Visitor A. POST is for data submission, GET is actually defined as a "read-only" mode in HTTP.

Two options for TYPO3 are:

  • switch to POST if there is no 100% necessity for GET in your use case
  • use the cHashExcludedParameters option in TYPO3 to disable all user-input values from the form.
1
votes

cHash is a security feature. It protects against maniuplation of parameters. And servers as an additional layer of security it also prevents a cache bloat attacks. Where a bot can generate links with new parameters and TYPO3 then caches the result of every such page and quickly grow the cache tables in the database.

It is however possible to exclude certain parameter from this caluculation using the install tool: [FE][cHashExcludedParameters] setting.

The excluded parameters then also do not affect the caching. (pages are cached as if the parameters are not present) but as you have a non-cacheable-action your result has to be generated on the fly anyway.

0
votes

Why is a cHash for a non-cachable action needed?

I dont really know. Maybe they just forgot it or no one really uses GET forms.

How can the cHash work on a form at all? It's the concept of a form that the user can modify the values, and as far as I understand it is the concept of the chash to prevent this.

The URL parameters are included in the chash. So sending via POST shouldnt take use of the chash except for the action/controller parameters.

You have to build the form by yourself and validate it manually or use Javascript. Indexed_search uses POST, changes the page/pointer ind the hidden form fields and submits the form again for the pagination.