[TYPO3-ect] tx_base - tslib_pibase modernized

[Elmar Hinz]

Hi Michael,

>> 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.
> 
> No. The USER_INT cObj will still have checkCHash disabled. I don't see a
> problem here.
> 

I expect the error Ernesto mentioned would be thrown, long before the
USER_INT would even be reached, but didn't do test exactly this in
practice, because I always have NotFouldOnCashError = 0. However the
conditions are given 

a) No cHash sent
b) checkChash triggert by some random USER object
c) pageNotFoundOnCHashErro = 1

=> Error

The cHash check happens for the whole page, not on extension level. It
can't be turned off for an isolated USER_INT in the page as you say above.
It not even tests the prefix of the parameters, it checks the URL as a
whole as you observe below. I have examined this behaviour with the
cherries extension from SVN, but didn't research the sources for it, so
there is a slight change that I am mistaken.

So the point of misconception is IMHO, that an event that works on page
level is triggert on extension level -- unpredictable by any random
extension in the page. This leads to completly wrong expections on what
can be done with this parameter. That makes it so difficult for everybody
to understand.

If even leading developers err in this, it shows that a simplification of
the system is really indicated. A have made my suggestion how it could be
done and it seems to match with to your own ideas you expressed some
postings before.

> 
> Currently, yes. I was thinking of a future scenario when cHash is used as a
> parameter check. For the moment, your proposal above makes sense.
> 
>>> 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.
> 
> There might be problems when you mix USER and USER_INT objects on one page.

Yes, it makes real sense to differ parameters from USER and USER_INT in
future versions. Even then I don't see conflicts with the suggested
principle: Always check & cache, if a cHash is given.

The system is simple to understand and keeps working in the same way for
the signed (cHashed) parameters of the USER plugin(s). 

It is that easy because the cHash is the singned wish of the developer
that the target page should be cached for this combination of parameters.
So we don't need a second confirmation on the target page. And a
confirmation that can be triggert by any random plugin on the target page
makes no sense at all, but only leads to confusion.

Regards

Elmar