delete
Ankündigung
Einklappen
Keine Ankündigung bisher.
PHP 7.4 MySQLi Database Wrapper
Einklappen
Neue Werbung 2019
Einklappen
X
-
Gast
Zitat von erc Beitrag anzeigen-escape in einem prepared statment?
-htmlspecialchars?!
Warum ist die Funktion fehl am Platz?
Edit: Habe den Fehler berichtigt, danke für dein Feedback. https://github.com/bpesch/DatabaseWr...292f9a175517e2
Kommentar
-
Zitat von bpesch Beitrag anzeigenWarum ist die Funktion fehl am Platz?
Man muss je nach Kontext unterscheiden, was, wie escaped werden muss.
- 1 Likes
Kommentar
-
Gast
Zitat von erc Beitrag anzeigenDas ist eine Funktion mit der Text in HTML eingefügt wird.
Zitat von erc Beitrag anzeigenWas hat das in einer Datenbankschnittstelle zu suchen? Was ist wenn ich die Daten nicht als HTML darstellen will
Zitat von erc Beitrag anzeigenoder ich HTML in der Datenbank speichern möchte?
Hier meine Korrektur: https://github.com/bpesch/DatabaseWr...607b1b9c2ea193
Der Schutz vor Injections ist jetzt optional.
LG
Kommentar
-
Gast
Zitat von sboesch Beitrag anzeigen
Weil HTML nichts mit der Datenbank zu tun hat.
Man muss je nach Kontext unterscheiden, was, wie escaped werden muss.
LG
Kommentar
-
Zitat von bpesch Beitrag anzeigenEine Datenbankschnittstelle sollte gegen HTML Injections arbeiten, deswegen benutze ich die Funktion
HTML Injections betreffen HTML, also die "View".
Zitat von bpesch Beitrag anzeigenSehr guter Punkt, da hast du natürlich Recht.
Hier meine Korrektur: https://github.com/bpesch/DatabaseWr...607b1b9c2ea193
Der Schutz vor Injections ist jetzt optional.
LG
- 1 Likes
Kommentar
-
Gast
Zitat von sboesch Beitrag anzeigen
Nein, eben nicht. Diese muss sich nur um SQL Injections sorgen machen.
HTML Injections betreffen HTML, also die "View".
Besser wäre es den "Schutz" einfach zu entfernen und an der richtigen Stelle zu schützen - der Ausgabe.
Außerdem sollte keine PHP Logik, wozu auch das Sichern vor der Injection zählt, in die View geschrieben werden. (Ausgenommen Smarty & Twig ähnliche Engines, falls du das als PHP Logik werten willst)
LG
Kommentar
-
Zitat von bpesch Beitrag anzeigenAußerdem sollte keine PHP Logik, wozu auch das Sichern vor der Injection zählt, in die View geschrieben werden. (Ausgenommen Smarty & Twig ähnliche Engines, falls du das als PHP Logik werten willst)
- 1 Likes
Kommentar
-
Gast
Zitat von hellbringer Beitrag anzeigen
Wo hast du diesen Unsinn her? Das stimmt natürlich nicht. Es gibt sehr wohl auch eine Ausgabelogik. Und darin fällt dann auch das Escaping.
Kommentar
-
Zitat von bpesch Beitrag anzeigen
Die View ist nicht für die Verarbeitung der Daten zuständig, nur für die Darstellung
bncms Bist du es? Falls nicht, siehe hiersorry, shift-taste kaputt
Kommentar
-
Zitat von bpesch Beitrag anzeigenDie View ist nicht für die Verarbeitung der Daten zuständig, nur für die Darstellung
Kommentar
-
Gast
Puh - Der Thread entwickelt sich bereits jetzt analog zu dem: https://www.php.de/forum/stellenange...-mitzuarbeiten
@bpesch: Jetzt wurden hier schon einige Sachen angemerkt und genau wie bncms fehlt bei Dir anscheinend jede Bereitschaft, allein mal darüber nachzudenken. Ich finde es durchaus löblich, dass Leute wie Du sich die Mühe machen, OS-Projekte zu betreiben. Aber wenn das grundlegende Anforderungen nicht erfüllt, sind sie eher kontraproduktiv.
_Wieso_ sollte sich ein _Datenbank_-Wrapper um etwas anderes kümmern als um das Datenbank-Handling? Mit Deiner Argumentation oben kannst Du ja gleich noch ein Routing implementieren, da ja nicht jeder eine Library dafür verwendet.
Gerade erst diese Antwort gesehen
EDIT: Der Scope dieser Klasse ist auch nicht richtig klar. Da wird DML und DQL zusammen geworfen, obwohl die im Kontext einer Applikation nichts miteinander zu tun haben sollten.
Ansonsten sind mir noch diese Punkte aufgefallen:
* Sehr simpel - Ich persönlich mag das.
* Warum ist CDatabase final?
* Warum ist der executionTimer public?
* Transactions würde ich auf jeden Fall mit aufnehmen.
* Den Type als Prefix in Namen aufzunehmen ist nicht mehr notwendig, seit man Variablen Type-hinten kann.
* Constructor hat, wie bereits erwähnt, im Interface nichts zu suchen. Das Interface würde ich noch mal nach DML und DQL separieren, wenn schon beides unterstützt werden soll.
* Insgesamt sollte so eine Klasse keinen State besitzen. Den hat sie aber und zwar z. B. mit dem Execution-Timer oder den prepared Statements. Das funktioniert nur, weil PHP kein Parallelizing unterstützt, ist aber trotzdem kein guter Stil
* Wie sieht es mit named Paramatern in prepared statements aus?
* Braucht das Projekt wirklich php 7.4? Vor allem sollte es wenn, dann >= sein.
Kommentar
Kommentar