[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