Frage zum Wiki-Artikel „PHP MySQL API“

[Der-Dennis]

Hallo Rolf,

auch Dir vielen Dank, dass Du Dir den Artikel durchgelesen hast und für Dein Feedback!

Aus meiner Sicht (aber das ist meine Privatmeinung) liegt der Schwerpunkt des Wiki im Browser, d.h. HTML, CSS und Javascript. Da steht SelfHTML in harter Konkurrenz zu MDN, was das Label "beste Doku" angeht, und ist im Rückstand (mangels Manpower?). Ob man dann ein weiteres Feld eröffnet, statt das bestehende Feld zu stabilisieren, ist eine Überlegung wert.

Ich ging bzw. gehe davon aus, dass das gewünscht war/ist. Zumindest wurde immer wieder angesprochen, dass insbesondere der PHP-Bereich mal etwas ausgebaut werden sollte, weil HTML, CSS und JS jetzt einigermaßen vollständig sind. Vielleicht sollte man das sonst nochmal hier im Forum thematisieren?

• die Formulierung "die Auswahl der API erfolgt in Bezug auf den konkreten Anwendungsfall" würde ich so nicht stehen lassen. "Anwendungsfall" bezeichnet für mich die fachliche Anforderung, die umzusetzen ist, und da sind mysqli/proc, mysqli/oo und PDO gleichwerting. Performance ist ebenfalls kein Kriterium, weil alle Anbindungen leichtgewichtige Hüllen um den eigentlichen C-Treiber sind. Auswahlkriterium ist eher die Vorliebe des Programmierers. Wenn man ein PHP-Programm objektorientiert aufzieht, wird man auch die OO-Schnittstelle von MySQLi nutzen wollen, oder gleich PDO. Wenn man ohne Objekte arbeitet bzw. von mysql auf mysqli umstellt, verwendet man die prozedurale Kapsel.

Ja, korrekt. „Vorliebe des Programmierers“ trifft es. Werde ich ändern.

• mysql wurde abgelöst, weil es Sicherheitslücken hat? Hast Du dafür einen Quelle?

Ja, Quellen sind auch dort angegeben. Zumindest ganz grob. Ich sprach aber nicht von „Lücken“, sondern allgemein von Sicherheit. Hoffe ich auf jeden Fall, weil konkrete Lücken sind mir nicht bekannt. Die Entwickler haben lange darüber diskutiert, was mit der Extension passieren soll. Anfangs stand vorallem die Sicherheit im Vordergrund, später dann neuere MySQL-Features, die mit der API nicht genutzt werden können und schließlich, dass man da auch nicht mehr viel Warten kann, weil das Ding immerhin schon fast 15 Jahre alt ist. Die Sicherheit ist auf jeden Fall mindestens als unterdurchschnittlich eingestuft. Auch im RFC von 2011 wird bereits davon gesprochen: „The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this.“

• die prozedurale Variante von mysqli weicht bei connect etwas von der OO-Schicht ab, new mysqli() liefert immer ein mysqli-Objekt, aber mysqli_connect liefert FALSE wenn ein Fehler auftritt. Deswegen bekommen mysqli_connect_errno() und mysqli_connect_error() auch keinen Parameter (siehe Doku, da steht void).

Korrekt. Da habe ich nicht aufgepasst.

Und um zu prüfen, ob $link = mysqli_connect(...) fehlschlug, soll man if (!$link) testen. (siehe Beispiel hier)

Ist das so? Kann ich zumindest aus der Doku ehrlich gesagt nirgendwo rauslesen.

• sprintf: Ist das in PHP das Mittel der Wahl? Ich kenne hauptsächlich Verkettungen per . Operator oder string parsing ("Hallo $dings")

Es ist zumindest nicht unüblich. Ich persönlich finde das auch etwas übersichtlicher

$sql = sprintf("SELECT ... WHERE a = '%s' AND b ='%s'",
    $mysqli->real_escape_string($a),
    $mysqli->real_escape_string($b));

als das

$sql = "SELECT ... WHERE a = '" . $mysqli->real_escape_string($a) . "' AND b ='" . $mysqli->real_escape_string($b) . "'";

• In der mysqli-Beschreibung sprichst Du korrekt vom Escaping für den Kontextwechsel. Aber im PDO Beispiel verwendest Du ein prepared statement - wo man nicht escapen muss. Deshalb ist es meiner Meinung nach falsch, dort von einem Kontextwechsel zu sprechen. Er ist hier nicht nötig, weil die Parameter nicht ins SQL eingebettet werden. Sie bleiben in ihrem eigenen Kontext erhalten. Statt dessen sollte darauf hingewiesen werden, dass prepared statements wegen der SQL Parameter kein Escaping benötigen.

Ja, ist richtig, kann man auch so machen. Solche Vereinfachungen habe ich an einigen Stellen drin, auch wenn sie technisch nicht komplett richtig sind. Ich will aber eigentlich keinen komplett neuen Kontextwechsel-Artikel schreiben oder ein Prepared Statements-Tutorial da einbauen. Die Idee war, einen groben Überblick zu geben und den Lesern nur trotzdem immer wieder klarzumachen, dass man auf sowas zu achten hat. Kann man ja nicht oft genug machen. Muss ich mal überlegen.

• Du könntest darauf hinweisen, dass auch mysqli prepared statements unterstützt (aber schlechter, weil es keine benannten Parameter gibt)

Ja. Das hab ich rausgelassen, weil ich ja nur eine grobe Übersicht geben will und - wie im ersten Posting geschrieben - eben nicht zeigen möchte, was man alles mit den APIs so machen kann.

und dass man in PDO auch eine Funktion für Escaping im Kontextwechsel hat, wenn man keine prepared statements verwenden will (PDO::quote).

Hab ich rausgelassen, weil die Doku schreibt, dass man quote zugunsten von Prepared Statements nicht nutzen sollte. Ich hatte das vorher drin, damit es besser vergleichbar mit den anderen APIs ist. Hab's dann aber doch für Prepared Statements nicht genommen, da das so ja schon sinnvoller ist.

Wenn man das vollständig zeigen will, muss man das Beispiel allerdings fünfmal statt dreimal bringen :)

Wenn das mal ausreicht :-)

Vielen Dank und Gruß
Dennis