[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