[TYPO3-dev] again issues with t3lib_div::_GP used in TS conditions

[Dmitry Dulepov]

Hi!

Franz Koch wrote:
> 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.

Not related to the problem but a side note: in my opinion it is not a good design when action URL contains parameters that must be submitted by POST. Typically all actions that change data must use only POST. It is a good convention and it is very sad that such a new module as Extbase breaks :(

> 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.

I assume you mean GParrayMerged? I see no problem with it, so I am willing to give my +1.

> So what do you guys think - bug or no bug? Shall I add a ticket in
> bugtracker?

Bug, to the bug tracker and RFC to the core list.

It would be good also to submit the issue for Extbase.

-- 
Dmitry Dulepov
TYPO3 expert / TYPO3 security team member
Read more @ http://dmitry-dulepov.com/