[TYPO3-commerce] $GLOBALS['TSFE']->set_no_cache() --> bad practice --> why using it?

Franz Koch typo.removeformessage at fx-graefix.de
Thu Sep 6 10:17:18 CEST 2007


Hi Ingo,

> Currently there are only 3 calls to set_no_cache in pi1. These calles 
> are only done, it the given get parameter are not correct, mainly if 
> someone is trying to change the parameter by guessing.
> We added in the last days checks if the given product uid and category 
> uid match to the selected categroy in the backend, so if these 
> parameters are not correct, we are showing the entry page for the plugin 
> and we don't want to get this page cached and indexed, since already the 
> call with the given parameter is wrong.

Well - that's what the cHash is for ;) No valid cHash for the given 
piVars, no caching as far as I know.

I also had a further look on that - isn't that the wrong way for trying 
to apply some more security? What good is it for if the parameters get 
(partly) passed to commerce and executed while the page get's not cached.
I think a much more secure way would be to enforce cHash parameters on 
every occasion. I found for example some places where commerce simply 
builds links with 'no_cache' for various things like:

- clear Basket link
- last product url
- link from basket to checkout

and maybe some other places I can't remember anymore. As Peter Niederlag 
confirmed: "USER_INT's are definitly never cached within TYPO3."

So I recommend to NOT use any links using no_cache, but strictly 
recommend to use cached links with a cHash, as THIS ensures secure link 
parameters and also provides the TYPO3 security mechanisms for cHash 
handling.

If the cHash doesn't match - simply clear EVERY piVar. That would be 
more secure IMHO. Or have I missed something? Would be good if a cHash 
expert could confirm.

--
Kind regards,
Franz Koch


More information about the TYPO3-project-commerce mailing list