[TYPO3-core] RFC: Enable pageNotFoundOnCHashError by default?

Ernesto Baschny [cron IT] ernst at cron-it.de
Wed Feb 28 10:09:30 CET 2007


Ingmar Schlecht wrote: on 28.02.2007 00:11:

> I'm not sure if it was a good idea to introduce this patch.
> 
> According to the last comments on http://bugs.typo3.org/view.php?id=4940
> there are quite a number of extensions having problems with the new
> default setting of pageNotFoundOnCHashError.

I agree that this will lead to various errors on most extensions. Those
can be corrected one by one, but for some the developer might be long
gone. This could be an oportunity to "clean up" the extension mess.

In particular I will have major impact because the method
pi_base::pi_getPageLink does not request typolink to set cHash, which is
what Franz pointed out in his note. This method is used by a ton of
extensions where the plugin is added on multiple pages (so that the
plugin can jump from one page to the other). This is the case for
example in the mentioned daimi_event for the link to the "registration
page" and was also the issue on tt_product. Franz patched this method in
fh_library's pibase variant so that it is possible to add a cHash.

So also in my opinion it is a bit too early to put this setting
defaulting to "true". I would rather wait until right after release of
4.1, then set this to true in trunk, and see that we release very early
an alpha of 4.2 with this in.  A production site won't upgrade to
4.2-alpha, but extension developers will like to play around with it. So
that we have several months of "testing phase" with this new default and
we can see what else we need to enhance in core so that this setting can
be used easily by most "average" extension developers (many of which
haven't got the "misteries of cHash" yet...).

> Apart from that, I could not see a security advantage at all in the new
> setting: The only thing this is about is whether an error-page should be
> shown or a non-cached page should be output to the user. No matter what
> the setting in question is, the user couldn't spam the cache table or
> anything, so no security gain here.

Preventing DoS attacks is also a security measure. I would try to set
this to "1" on sites where I know all extensions, so that there is no
chance that the load on the server gets too high because of some
attacker hitting on a buggy extension with various random parameters.


Cheers,
Ernesto


More information about the TYPO3-team-core mailing list