set Methode in Contao\Database\Statement escaped Keys nicht

[xat]

Mir ist aufgefallen, dass in der set Methode der Contao\Database\Statement Klasse zwar die Values des reingereichten Arrays escaped werden, nicht aber Keys.

Siehe: https://github.com/contao/core/blob/master/system/modules/core/library/Contao/Database/Statement.php#L187

Ist das Escapen der Keys prinzipiell dem Entwickler ueberlassen oder sollte hier im Core auch noch eine Pruefung stattfinden?

[leofeyer]

Was willst Du denn bei den Keys groß escapen? Das sollten ja immer Feldnamen in der Datenbank sein und da gibt es keine Sonderzeichen.

[xat]

Jo, Feldnamen duerfen halt auf keinen Fall ungeprueft vom Frontend kommen. Z.b. aus einem Formular indem die Namen der Inputs den Spaltennamen entsprechen. Was ja an fuer sich logisch ist. Dennoch dachte ich z.B. (bevor ich mir die Implementierung angeschaut hab) dass mich die set Methode nochmal zusaetzlich schuetzt da sie ja Bestandteil eines prepared Statements ist.

[leofeyer]

Gibt es einen konkreten Fall, anhand dessen ich das nachvollziehen könnte?

[aschempp]

Was ist mit ->set() ? Da werden ja alle Keys einfach übernommen?

[xat]

@leofeyer

Ich kann dir keine Stelle nennen wo die Spaltennamen nicht vorab nochmal ueberprueft werden. Allerdings hab ich jetzt auch nicht den kompletten Contao Code einem Audit unterzogen, daher kann ichs auch ned ausschliessen dass es nicht doch irgendwo ne Stelle gibt wo der Key vom User kommt. Und die eine oder andere Extension schwirrt da draussen sicherlich rum die nen ->set($_POST) macht.

Spricht denn generell was dagegen die Keys jeweils nochmal mit einem -Zeichen zu umhuellen und davor die -Zeichen im Key-Namen durch einen Leerstring zu ersetzen?

[leofeyer]

Ja, die Tatsache, dass wir nirgends Tabellen- oder Feldnamen escapen, weil das MySQL-spezifisch ist und sonst den DBAL zerschießt.

[discordier]

Ehm, das escapen muss auch der Treiber selbst machen.
Schnelle Recherche ergab, dass das Quoten mitnichten MySQL spezifisch ist (ich kannte es auch schon vorher von anderen DBs).

Jedoch variiert es wie folgt:
SQL-92 specification: <delimited identifier> ::= <double quote> <delimited identifier body> <double quote> (sec 5.2) und somit: CREATE TABLE "WHERE" VARCHAR(1);

Nun wird es aber interessant:

• MSSQL versteht anscheinend "WHERE" und [WHERE] (letzteres war mir bereits bekannt).
• Oracle versteht den Standard "WHERE"
• MySQL versteht nur seine backticks solange man nicht SET GLOBAL SQL_MODE=ANSI_QUOTES;aktiviert, ist dies erfolgt versteht auch MySQL den Standard"WHERE"..
• Postgres versteht den Standard "WHERE".
• SQLite versteht den Standard "WHERE" und [WHERE]
• Sybase versteht anscheinend "WHERE" und [WHERE].
• DB2 versteht den Standard "WHERE"
• Apache Derby versteht den Standard "WHERE"
• H2 versteht den Standard "WHERE"
• HSQLDB versteht den Standard "WHERE"

Somit ist MySQL der EINZIGE (grosse) der den SQL92 Standard in dieser Hinsicht NICHT per default supported sondern nur mit flag.

Man kann also durchaus eine Treibermethode protected function escapeIdentifier() o.ae. implementieren.

Edith Quellennachweis:
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
http://dba.stackexchange.com/questions/29815/is-there-a-major-rdbms-that-doesnt-allow-column-name-quoting-escaping

[xat]

+1 fuer die abstrakte methode escapeIdentifier() die in den jeweiligen DB Subklassen dann entsprechend implementiert wird.

[leofeyer]

@contao/developers Was ist also hier zu tun?

[Toflar]

+1 fuer die abstrakte methode escapeIdentifier() die in den jeweiligen DB Subklassen dann entsprechend implementiert wird.

Ich denke das :) Wobei ich jetzt so frech wäre und Simon für einen PR fragen würde :D

[leofeyer]

Wie am 19. Juni auf Mumble besprochen, wollen wir das nicht unterstützen. Weitere Informationen dazu findest Du z. B. hier: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/basic-mapping.html#quoting-reserved-words