[TYPO3-dev] WARNING!?? tslib_patcher, pp_chashchecker

[Michael Stucki]

Hi Elmar,

thanks for pointing on this. I already stumbled over tslib_patcher earlier
this week, but had a closer look at it now.

> two extension have been uploaded to TER claiming to "correct bugs related
> to the cache hash" and/or to "increase the overall performances of your
> TYPO3 website".
> 
> tslib_patcher and pp_chashchecker
> 
> 
> Do this extensions really do what they promise to do or do they make
> matters worse?

Well, it's pretty time-consuming to make a diff of all these changes.
Therefore, I only had a look at the manual so far.

> I am not fully sure, how they work, and there isn't that much
> documentation.

There is a documentation, but it seems like typo3.org doesn't render them
anymore(?)

Quoting the manual of tslib_patcher:

| The cHash URL parameter is used when URL parameters other than id, type,
| etc are used, in order to cache the page state. As said in the official
| documentation:
| «Each link involving more parameters than the &id must
| contain ?&cHash=[hash string]? in addition. The value of ?&cHash? is used 
| on the server to verify that the combination of additional parameters is
| made by the server itself and not forged by an outside spammer.»

Sounds like a security enhancement (checkHash) rather than a performance
improvement (cacheHash). And I think this is pretty much the same problem
as described here: http://bugs.typo3.org/view.php?id=5010

| Unfortunately, the core typoLink function, which is used in TypoScript and
| usually in TYPO3 extensions, is buggy and does not generate correctly the
| cHash.

Unfortunately, the documentation does not describe these bugs in more
detail. Hard to say what it changes, hard to say if it's needed. After all
I wouldn't trust such an extension without making a deep analysis of it.

In my opinion, this is a pretty bad way of contributing. Fixing bugs using
XCLASS extensions but not even making a bugreport about it makes me wonder
if the extension author wants the problem to be solved.

(And since I know the author, and he released some really good stuff
already, I wonder even more why he was publishing such an extension...)

Continuing quote from the extension manual:

| In addition, there is absolutely no support for the cHash in the core TS
| menus. This last case is really problematic when you use the RealURL
| extension, and/or if you have a multi-language website. For instance, if
| you take that URL: http://mydomain/en/typo3-test-page/index.html (which is
| a RealURL URL), it means something like
| http://mydomain/index.php?id=35&L=1. 
| As you can see, with RealURL, there is always the L variable in the URL.
| So a cHash is requested. As the TS menus did not generate the cHash, it
| causes problems to the TYPO3 mechanism.

I think it's a wrong assumption that the L parameter requires a cHash. But I
have seen the situation where L parameters were appended by URLs, and
therefore I understand the reason for that.

However, in such a situation, using the condition feature for
config.linkVars seems to be much easier:

config.linkVars = L(1,2)

This means: don't append &L if it is "0" (because then it's not needed) or
any value beyond "2".

Back to Elmars posting:

> To me it looks, that they check for a cHash whenever GET parameters are
> sent, even if GET parameters are send without a cHash to a USER_INT plugin
> by intention. That's the situation of well configured result browser links
> of search forms.
> 
> In this case, according to my understanding, the check would fail and the
> complete page would not be cached but rerendered. That would have the same
> effect like sending the harmful "no_cache=1" parameter. The performance of
> high frequented search forms would decrease in a dangerous way.

It won't fail as long as the cHash is correct. But you are still right: The
page will be re-rendered because the cHash (making this page unique) does
not exist in the DB cache, like it would have been the case with result
browsers, e.g. in pi_indexedsearch. So as you can see, adding &cHash to
every URL seems not useful in all situations.

(Just for clarification: USER_INT objects are represented by a placeholder
on a cached website. This works fine as long as there is no cHash on a page
and therefore always the same record is read from the cache.)

> I am not fully sure about the mechanism. But I warn, not to use this
> extensions until there is a positive feedback from side of Michael Stucki
> that they really do no harm.

If you have USER_INT objects, it will most likely result in a slowdown. The
same effect (preventing misuse of linkVars parameters) can be reached much
easier with the example which I wrote above.

> What is your estimation. What do this extensions do? Do we need to send a
> warning to the user lists?

Generally one should never install extensions if he doesn't know what it
really does. This is very true for this one...

I wouldn't say this needs a warning, but it's a good example that shows that
self-initiatives (fixing bugs and releasing extensions without discussing
the need for them) are a bad option if an extension author is on the wrong
track...

- michael
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/