[TYPO3-dev] again issues with t3lib_div::_GP used in TS conditions
Franz Koch
typo3.RemoveForMessage at elements-net.de
Wed Apr 7 15:59:21 CEST 2010
Hi,
I already started a topic about this issues some years ago I think - and
today stumbled again over it on a live website where it was responsible
for quite some trouble with sensible user data. So I thought I restart
the discussion about it.
Issue: t3lib_div::_GP is used for resolving TS-conditions (see example
below) and either returning a value from _GET OR _POST with precedence
on only _POST instead of using a merged array like t3lib_div::_GPmerged
does.
Example: The following condition is a example created by extbase.
[globalString = GP:someExtKey|controller = Foo] && [globalString =
GP:someExtKey|action = bar]
#do something
[global]
This condition will ONLY match if there are only GET or only POST
parameters, but not if f.e. the controller is given in POST but the
action via GET.
This is f.e. the case in extbase based forms by default - where I
recently had the mentioned issue on a live website.
Some might say now, why don't you strictly check for _GET or _POST then?
Because it's not possible in this case. Extbase doesn't know for what to
build the condition for (GET or POST) and it actually could be needed
for both thinking about a page/URL that should be fetched via a AJAX
POST request, but could also be triggered via GET without JS enabled. So
the same condition has to match either way.
My proposal would be now, to use t3lib_div::_GPmerged instead in
t3lib_matchcondition_abstract.
So what do you guys think - bug or no bug? Shall I add a ticket in
bugtracker?
--
kind regards,
Franz Koch
More information about the TYPO3-dev
mailing list