Ankündigung

Einklappen
Keine Ankündigung bisher.

PHP 7.4 MySQLi Database Wrapper

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • PHP 7.4 MySQLi Database Wrapper

    Hi, ich bin neu hier!

    Ich habe einen PHP 7.4 MySQLi Database Wrapper geschrieben & bin gespannt auf Kritik und Feature Vorschläge.
    Hier der Link: https://github.com/bpesch/DatabaseWrapper

    LG


  • #2
    -escape in einem prepared statment?
    -htmlspecialchars?!

    Kommentar


    • #3
      Zitat von erc Beitrag anzeigen
      -escape in einem prepared statment?
      -htmlspecialchars?!
      Den escape Punkt verstehe ich, den htmlspecialchar Punkt aber nicht.
      Warum ist die Funktion fehl am Platz?

      Edit: Habe den Fehler berichtigt, danke für dein Feedback. https://github.com/bpesch/DatabaseWr...292f9a175517e2

      Kommentar


      • #4
        Das ist eine Funktion mit der Text in HTML eingefügt wird. Was hat das in einer Datenbankschnittstelle zu suchen? Was ist wenn ich die Daten nicht als HTML darstellen will oder ich HTML in der Datenbank speichern möchte?

        Kommentar


        • #5
          Zitat von bpesch Beitrag anzeigen
          Warum ist die Funktion fehl am Platz?
          Weil HTML nichts mit der Datenbank zu tun hat.
          Man muss je nach Kontext unterscheiden, was, wie escaped werden muss.

          Kommentar


          • #6
            Zitat von erc Beitrag anzeigen
            Das ist eine Funktion mit der Text in HTML eingefügt wird.
            Ich weiß, deswegen verwende ich sie.

            Zitat von erc Beitrag anzeigen
            Was hat das in einer Datenbankschnittstelle zu suchen? Was ist wenn ich die Daten nicht als HTML darstellen will
            Eine Datenbankschnittstelle sollte gegen HTML Injections arbeiten, deswegen benutze ich die Funktion

            Zitat von erc Beitrag anzeigen
            oder ich HTML in der Datenbank speichern möchte?
            Sehr 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

            Kommentar


            • #7
              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.
              Siehe Antwort an erc

              LG

              Kommentar


              • #8
                Zitat von bpesch Beitrag anzeigen
                Eine Datenbankschnittstelle sollte gegen HTML Injections arbeiten, deswegen benutze ich die Funktion
                Nein, eben nicht. Diese muss sich nur um SQL Injections sorgen machen.

                HTML Injections betreffen HTML, also die "View".

                Zitat von bpesch Beitrag anzeigen
                Sehr 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
                Besser wäre es den "Schutz" einfach zu entfernen und an der richtigen Stelle zu schützen - der Ausgabe.

                Kommentar


                • #9
                  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.
                  Da nicht jeder ein MVC oder eine Template Engine benutzt, die gegen Injections arbeitet, lasse ich die Option drin, obwohl ich deinen Punkt verstehe.
                  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


                  • #10
                    Zitat von bpesch Beitrag anzeigen
                    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)
                    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


                    • #11
                      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.
                      Die View ist nicht für die Verarbeitung der Daten zuständig, nur für die Darstellung

                      Kommentar


                      • #12
                        Zitat von bpesch Beitrag anzeigen

                        Die View ist nicht für die Verarbeitung der Daten zuständig, nur für die Darstellung
                        Daher ist htmlspecialchars auch nur für die Darstellung und nicht für die Verarbeitung in der Datenbank.
                        bncms Bist du es? Falls nicht, siehe hier
                        Eine Mannschaft aus Granit! So wie einst Real Madrid!
                        Und so zogen wir in die Bundesliga ein und wir werden wieder Deutscher Meister sein!

                        Kommentar


                        • #13
                          Man sollte in einem Interface auch nicht den Constructor fest vorgeben.

                          Kommentar


                          • #14
                            Zitat von bpesch Beitrag anzeigen
                            Die View ist nicht für die Verarbeitung der Daten zuständig, nur für die Darstellung
                            HTML-Escaping gehört zur HTML-Ausgabe und nicht zur Verarbeitung.

                            Kommentar


                            • #15
                              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.

                              @bncms Bist du es? Falls nicht, siehe hier
                              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

                              Lädt...
                              X