[TYPO3-dev] RFC #11120: stdWrap for TypoScript-select parameters

David Bruchmann typo3-dev at bruchmann-web.de
Tue Jun 9 08:15:16 CEST 2009


----- Ursprüngliche Nachricht -----
Von:        Jigal van Hemert <jigal at xs4all.nl>
Gesendet:   Dienstag, 9. Juni 2009 06:46:53
An:         List for Core-/Extension development 
<typo3-dev at lists.netfielders.de>
CC:
Betreff:    Re: [TYPO3-dev] RFC #11120: stdWrap for TypoScript-select 
parameters
>>> TypoScript requires that values keep untouched referring quotes
>>> because stWrap and other Options can be inherited - Quoting could
>>> breakdown the concept.
> 
> Can't we take a different approach?
> If there would be a new type of select function which functions like a PDO
> prepare() function [1]?
> This should force the use of some kind of markers (similar to the way
> constants are now inserted as data: {$constant} ) and thus the quoting and
> escaping can be left to the core.
> 
> The marker definitions should allow for full stdWrap (and perhaps more) to
> enable integrators to build the right values for the markers.
> 
> [1] http://www.php.net/manual/en/pdo.prepare.php
> 


Hi Jigal,

I never worked with PDO::prepare but as far as I understand the manual 
you linked, each allowed variable has to be binded which means it has to 
be defined and a prepare-statement has to be build.
SQL-Statements from TS aren't known to the core, so there had to be 
build a completley new function or class that handles these statements.

Another point: Well done SQL-Injection has a sense for the database and 
is calling existing tables and fields. Sending Statements to the core 
you have to determine if the statement has to be interpreted or not 
anyway. It's not possible for a abstract class to verify which 
statements are guilty from administrative view.
I think decision about quoting have to be made from the functions they 
send the requests.
In my opinion we've only to find a function that quotes everything we 
want without destroying referenced classes and userscripts that are 
based on these references. Due to the fact that I never worked a lot 
with joins and complicated SQL-Statements I was unsure if the function 
$GLOBALS['TYPO3_DB']->fullQuoteStr() can do this job.

Other points are:
1) The code shouldn't be so hard to read (that's not from me but from a 
core-developer, nevertheless I agree ;-) )
2) The normal t3lib_db.php-file is or should be only a wrapper-function 
and we've to keep in mind that there are also other databases than mySql.
3) when the PDO-library is really used (instead of rebuilding some 
funtions like I understood you) the question occures if it's available 
for different combinations of Servers (Apache, MySQL, ... - Hardware 
doesn't matter I think) and Operating-Systems.
4) I've the impression that your proposition does change a lot and is 
able to brake down functionality of core-parts and extensions.
5) Creating new markers wouldn't be backward-compatible I think or the 
work to integrate it compatible would be quite huge.

Perhaps I misunderstood you and my doubts are without legal cause.
Question is: who will integrate your idea?
When you're sure it works perhaps you should do that?

Open for propositions and corrections ;-)

Best Regards
David





More information about the TYPO3-dev mailing list