[TYPO3-ect] tx_base - tslib_pibase modernized

[Elmar Hinz]

Hi,

> 
> Let's say this: Usually a cached object is a USER object and has
> $this->pi_checkCHash set to TRUE, while for non-cached objects (USER_INT) it
> is the opposite. I'm aware that it's currently possible to do this
> differently, but practically I see no sense in it. For me it seems ok to
> require that cached objects require cHashes all the time.
> 
> So maybe we could just set $this->pi_checkCHash and $this->pi_USER_INT_obj
> automatically, like this:


I already have thought about this solution, but I fear it isn't that
easy.

Imagine a typical search from (USER_INT) with a result browser
(unlimited combinations of parameters). In the border there are a few
little, nice static plugins (USER). In this case the USER plugins
don't depend on parameters. (In fact they couldn't because we need a
flexible URL for the result browser.)

In your suggestion each of this USER plugins would trigger checkCHash, if
I understand it right. The USER plugins in the borders have themself no
parameters to receive, but they would influence the USER_INT in the same
way as if we would always activate checkCHash. Right? So we
would run into the same problems with pageNotFoundOnCHashError = 1.

> 
>> Maybe it's a kind of conceptional bug in the core. The current fix
>> of this bug is to ser pageNotFoundOnCHashErr=0. Wouldn't it be possible to
>> alter the pageNotFoundOnCHashError behaviour by an additional condition:
>> 
>> *******************************************************************
>> Only check the cHash if a cHash has been given.
>> *******************************************************************
>> 
>> That would IMHO solve the problem.
> 
> This would work with USER_INT objects, but still I dislike the solution
> because this way you can just remove the cHash from a URL and send whatever
> you want to that page. I would rather like to enforce the cHash to me it is

Isn't that exacly what you typically do with USER_INT? I don't see the
problem here.

> not only a "cacheHash" but also a "checkHash". One day I would like to use
> it for solving the "&no_cache=1" problem...

That is exactly my theses. Check&Cache whenever a valid cHash is send. The
control should happen in the moment the cHash is created. Quite simple.

Regards

Elmar