http://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692009-05-29T16:31:01ZTYPO3 ForgeTYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520342009-05-29T16:31:01ZOliver Haderoliver.hader@typo3.org
<ul></ul><p>Concerning stdWrap functionality for groupBy and orderBy there's already a patch pending in the core list as RFC <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Enable stdWrap on select properties groupBy and orderBy (Closed)" href="http://forge.typo3.org/issues/20508">#20508</a></p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520352009-05-30T16:14:19ZDavid Bruchmannagentur@bruchmann-web.de
<ul></ul><p>Hello Oliver,</p>
<p>Your Solution is a particial one. I don't see any reason to restrict changes to the two parameters you choosed. Another Bug also solved a single Option: <a class="external" href="http://bugs.typo3.org/view.php?id=7921">http://bugs.typo3.org/view.php?id=7921</a>.<br />I have another Solution respecting all possible Parameters but this is incompatible with yours because for some parameters I integrated the choice to stdWrap it or not - that's not possible with your proposition.<br />Furthermore I added two more parameters to influence behavior:<br />1) $conf['pidInList']['dontSetPid'] to avoid that empty pidInList is filled with "this" <br />2) $conf['andWhere']['dontUseStdWrap'] to avoid that addWhere is stdWrap_ped by default</p>
<p>I'll posted a new patch (_2), futhermore a small extension to test different queries will coming soon.</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520362009-05-30T17:19:56ZDavid Bruchmannagentur@bruchmann-web.de
<ul></ul><p>Mhm, something still isn't perfect with patch 2. Damned.</p>
<p>Uploaded patch 3 where some faulting behavior in loop was fixed.</p>
<p>Will test more.</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520372009-05-30T20:55:14ZDavid Bruchmannagentur@bruchmann-web.de
<ul></ul><p>found one typo and shortend inquiries a bit in patch 4<br />Tests I build until now are proceeded correct</p>
<p>changed parameter-name to avoid misunderstanding in patch 5</p>
<p>corrected search for parameters in lines 7166, 7167 in patchh 6</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520382009-06-01T11:56:03Ztyler kraftheadhunterxiii@yahoo.ca
<ul></ul><p>+1</p>
<p>I'd like to see this in 4.3</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520392009-06-02T10:38:53ZJo Hasenauinfo@cybercraft.de
<ul></ul><p>As long as TypoScript select is using stdWrap without escaping the results of the stdWrap functions before executing the SQL query, any stdWrap call for any select parameter IMHO is a no go!</p>
<p>select.blah.data = GPvar:blah</p>
<p>will open up a nice way for MySQL injections without the admin ever noticing it, since he might not have access to the source to check, if the values are escaped. Many people might think they are escaped and rely on the core to handle the stuff properly (which it does not) - so there should be a fix to the existing problem before adding even more options to create security holes.</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520402009-06-06T20:14:16ZDavid Bruchmannagentur@bruchmann-web.de
<ul></ul><p>Hi Jo,</p>
<p>what do you think about "where", "andWhere" and the different joins referring stdWrap?</p>
<p>Regards<br />David</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520412009-06-07T20:23:56ZDavid Bruchmannagentur@bruchmann-web.de
<ul></ul><p>It's simple to change some lines like that:</p>
<p>from <br /> // Fields:<br />$queryParts['SELECT'] = $config['selectFields'] ? $config['selectFields'] : '*';</p>
<p>to this:<br /> // Fields:<br />$queryParts['SELECT'] = $config['selectFields'] ? $GLOBALS['TYPO3_DB']->fullQuoteStr($config['selectFields'],$table) : '*';</p>
<p>I just need a hint which elements of $queryParts have to be changed, "SELECT" is clear after Jo's hint but I'm not sure about all the other parts.</p>
<p>I'm awaiting your comments ;-)</p>
<p>PS: concerns the functions tslib_cObj::getQuery() and tslib_cObj::getWhere()<br />Adding patch 8 with changes so far.</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520422009-06-08T14:30:18ZJo Hasenauinfo@cybercraft.de
<ul></ul><p>Well - the current situation already is exactly as I described in my post. It doesn't matter which part of the SQL query you send through stdWrap, as long as the result is not properly escaped, the possibilities are the same.</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520432009-07-14T10:49:01Ztyler kraftheadhunterxiii@yahoo.ca
<ul></ul><p>Hi Joey,</p>
<p>I agree with your concerns regarding security, but at the same time the select property is very limited because of the fact that we can't use stdWrap on many parts of it. For instance at the moment I'd like to be able to use stdWrap to get a variable and use it with the begin property - but I can't and that makes it very frustrating to try to use.</p>
<p>There has to be a way to have security and stdWrap ability? And surely the T3 admin in question should be aware of the fact that there is the possibility for MySQL injections and use intval with stdWrap to prevent this? (This can be mentioned in TSref that they should be doing this).</p>
<p>While not wanting to open up security issues (of which I'll openly admit that I don't know much about) we shouldn't be babysitting because of poor T3 developers? By that token shouldn't we then remove the PHP, PHP_INT, USER and USER_INT content types from the core as they could also introduce security issues? And should we remove the pre/post user functions form stdWrap because they could then open up security issues anywhere?</p>
<p>Just my thoughts, but I could be wrong. I'm sure that there must be a way to make these properties usable with stdWrap but also secure - I just unfortunately can't really contribute as I'm not a PHP guy (but I can't use stdWrap.intval=1 ;-) )</p>
<p>Ty</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520442009-08-26T18:35:48Ztyler kraftheadhunterxiii@yahoo.ca
<ul></ul><p>Hi</p>
<p>With feature freeze being imminent for 4.3, what are the chances of this being included?</p>
<p>This would be very very helpful if it was, as it would allow a new wider range of uses and flexibility for the select in typoscript.</p>
<p>Tyler</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=520452011-01-17T21:37:21ZErnesto Baschnyeb@cron.eu
<ul></ul><p>Fixed in <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Optimize stdWrap usage for tslib_content (Closed)" href="http://forge.typo3.org/issues/24089">#24089</a> by the stdWrap optimization project. Will be included starting 4.5.0 (beta3).</p> TYPO3 Core - Bug #20529: stdWrap for TypoSrcrip-select parametershttp://forge.typo3.org/issues/20529?journal_id=617452011-03-29T14:22:48ZSusanne Moogsusanne.moog@typo3.org
<ul><li><strong>Target version</strong> deleted (<del><i>4.5.0</i></del>)</li></ul>