get rid of chash in route enhancer for plugin

Question

How is it possible to get rid of the cHash-Parameter in a pi_based extension? The manual says:

"The requirements section exactly specifies what kind of parameter should be added to that route as regular expression. This way, it is configurable to only allow integer values for e.g. pagination. If the requirements are too loose, a URL signature parameter ("cHash") is added to the end of the URL which cannot be removed."

But how strict is strict? My configuration:

Lexikon:
  type: Plugin
  limitToPages: [2140]
  routePath: '/eintrag/{eintrag}/{buchstabe}'
  namespace: 'tx_mcflexikon_pi1'
  requirements:
    buchstabe: '[A-Z]{1}'
    eintrag: '[0-9]{1,4}'
  default:
    buchstabe: 'A'
    eintrag: '0'

I don't how i could define more strict rules other than these: 1 letter and 1 to 4 digits.

Thanks!

Answer 1

Well after a few hours i found a workaround. It seems that the definitions in section requirement are not really important for cHash-Handling. Far more important is the aspects section. If i define for every parameter an aspect the cHash vanishes:

Lexikon:
  type: Plugin
  limitToPages: [2140]
  routePath: '/eintrag/{buchstabe}/{eintrag}'
  namespace: 'tx_mcflexikon_pi1'
  requirements:
    buchstabe: '[A-Z]{1}'
    eintrag: '[0-9]{1,4}'
  default:
    buchstabe: 'A'
    eintrag: '0'
  aspects:
    eintrag:
      type: PersistedAliasMapper
      tableName: 'tx_mcflexikon_daten'
      routeFieldName: 'slug'
    buchstabe:
      type: StaticValueMapper
      map:
        A: 'A'
        B: 'B'
        C: 'C'
        D: 'D'
        E: 'E'
        G: 'G'
        H: 'H'
        I: 'I'
        J: 'J'
        K: 'K'
        L: 'L'
        M: 'M'
        N: 'N'
        O: 'O'
        P: 'P'
        Q: 'Q'
        R: 'R'
        S: 'S'
        T: 'T'
        U: 'U'
        V: 'V'
        W: 'W'
        X: 'X'
        Y: 'Y'
        Z: 'Z'

It is a bit annoying to define every letter but i found no other possibility; the StaticRangeMapper and PersistedAliasMapper do not work in this context.

Perhaps it is possible to define a custom mapper which does nothing in order to trick the system. On the other hand: this would obviously result in a security problem.