TYPO3 Core

In general you are right, sites that have this problem are not setup 100% correct. On the other hand the update and fix for changed cHashes and proper setup with realurl does require a lot of work and knowledge on large and complex sites. Compared to the risk of cache flooding there are business decisions that justify the decision for setting cHashIncludePageId=FALSE.

It would be nice if this could be set with some acknowledge flag and not send out a daily reminder. Other problems will otherwise easily get lost, because the report will be disabled alltogether or not read anymore.

Hi Stephan,

we had a longer discussion here talking about very large (!) systems and we can not make sure, that there is NO external stored (cHash containing) link at all.
As far as the bug report could be understood that it's optional [1] to turn this on, I wonder why this issue is not set to warning instead of error (...or the way Peter mentioned).

[1] "Because of this major impact on existing installations, please carefully consider when to activate this additional security option for your TYPO3 installation"

I have an other argument.
Here are two example links.

http://domain.tld/46.html?&tx_ttnews%5Btt_news%5D=4678&cHash=54018808acc5745393409312ccb498b1
http://domain.tld/News-Details.23+M5d130b574a1.0.html

Both come from systems, using simulate static documents.
The first one will not work anymore after setting cHashIncludePageId=true and about the second I'm almost sure that it will change either.

Both links are "fine" or "okay" or in other words, there is nothing wrong about them except they look ugly.
The same for examples like "index.php?id=46?&tx_ttnews%5Btt_news..."
And "yes"... customers who use simulate static documents since years will use it under 7 or 8 as well!

I know no law, that you have to use RealURL.
So what's about all others?

Peter Niederlag wrote:

Compared to the risk of cache flooding there are business decisions that justify the decision for setting cHashIncludePageId=FALSE.

I agree.

It would be nice if this could be set with some acknowledge flag and not send out a daily reminder.

I agree.

Other problems will otherwise easily get lost, because the report will be disabled altogether or not read anymore.

But what about other (security related) reports?
It might e.g. be reasonable to disable the trusted hosts pattern in certain situations.

So, for your concrete project, in your concrete setup (send failing reports via mail), the situation could be improved.
There are some options you have already now without a core change:

• you apply a patch
• you choose another (less limited) reporting technique instead of sending mails
• you filter out these exact mails (should be fairly simple with most mail hostings)

Other than that, we could of course improve the reporting here, but then we should implement a general solution with the possibility to disable
every single report and make no exceptions for one specific use case. Suggestions how to approach that are welcome. Code changes are welcome of course as well.

Erik Sokoll wrote:

Both links are "fine" or "okay" or in other words, there is nothing wrong about them

Sure

And "yes"... customers who use simulate static documents since years will use it under 7 or 8 as well!

Nothing wrong with that.

I know no law, that you have to use RealURL.
So what's about all others?

It is not about forcing anybody to do anything. It is about finding a good middle ground and mitigation for everybody.

If you have concrete suggestions how to solve this security issue better for every single TYPO3 user and installation (not only covering your case), whether to have a switch or not, how to mitigate the cache flooding possibility in a different way with less impact, I'm happy to hear about that and of course will consider or even schedule a change.

So, go ahead, make TYPO3 better for everybody. Thanks!