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

[Popy]

2007/8/23, Michael Stucki <michael at typo3.org>:
>
> 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 what about http://bugs.typo3.org/view.php?id=5531,
http://bugs.typo3.org/view.php?id=5161 and
http://bugs.typo3.org/view.php?id=5117 ? The bug is reported since 5 monthes
and nothing is done in the source (even in latest developpement revision)


(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...)

Maybe because for now this is the only way to have valid cHashes in url ?


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.

As the L var is not a core parameter, it has to be cHashed. For now
multilingue websites works with ne cHash because of the typoscript
conditions [L = x] (which have an important place in cache hash)


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.)

This is right. Read http://bugs.typo3.org/view.php?id=5531, we are speaking
about a kind of "cHash tunnel", and i did say i was ready to patch some core
file to make an example. No response about this for now.


> 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.

Little slowdown or multiple cached pages for a single USER_INT plugin, yes.
But most of the plugins should be USER plugins !


> 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...

Discussions were launched on the bugtracker, and nobody takes care. So
instead of manually patching every Typo3 release on all our websites, we did
choose to make extensions wich patch the core files.

Is there a better way ? You know the tslib_patcher author, and maybe you
know my extensions too, so you should know that we always look for the
better solution.
-- 
Popy

Vulnerant omnes, ultima necat.

http://popy.sytes.net