[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