Ankündigung

Einklappen
Keine Ankündigung bisher.

Fragen zu Prepared Statements

Einklappen

Neue Werbung 2019

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

  • Fragen zu Prepared Statements

    Diese Prepared Statements werden teils als Heilsbringer angepriesen. Ich habe mir die Sache auch schon einmal angesehen, in der PHP Dokumentation. Doch die ist alles andere als überzeugend. Da werden Prepared Statements mit Objektorientierter Stil und Prozeduraler Stil wild durcheinandergemixt und es bleiben unendlich viele Fragen offen, die auf irgendwelchen Webseiten von irgendwem irgendwie beantwortet werden und am Ende weiß man nicht woran man ist. Ein paar Beispiele.

    Man erstellt also ein Prepare Query:
    $stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)");
    der dann anstelle des Platzhalter ? gefüllt werden kann.
    $stmt->bind_param("i", $id);
    zuletzt dann noch ein
    $stmt->execute();
    Wieso füllt man den Platzhalter ? Parameter nicht gleich? Wäre doch weniger Aufwand. Zumal, denn jetzt wird es seltsam und komplex:
    Wie sieht es aus, wenn mehrere Parameter ge-bind-et werden sollen? Da gehts schon los. Die PHP doc löst die Frage, indem sie Objektorientierten Stil verwendet. Feine Sache!
    Was ist mit NULL von PHP nach MySQL? Das scheint simpel zu sein, anscheinend, oder dann doch nicht, weil der bind Typ angegeben werden muss. Hier fehlen mal wieder praktische Beispiele, und es sind nur theoretische zu finden, die fein säuberlich Ziffern anstatt Variablen in Statements verwenden. Wenn ich sowas sehe ist es eh schon aus.
    $mysqli->query("INSERT INTO test(id, label) VALUES (1, 'a')"));
    Ja PHP, ich setze mich hin und fülle jedes Statement manuell aus, 24/7, thas my life! Aber nur, weil ich mir keine kleinen Chinesen leisten kann, die in Servern wohnen und das für mich machen würden.
    Im Internet findet man dann gleich sowas, womit das bind als deprecated eingestuft werden kann, weil mans eh nicht braucht.
    $stmt = $mysqli->prepare("INSERT INTO login(`name`,`password`,`email`,`sex`,`city`) VALUES(?,?,?,?,?)");
    $stmt->execute([$name, $pass, $email, $sex, $city]);
    Da fehlt dann auch arbeitserleichternd die Angabe eines Typs. Feine Sache! Nur, was ist daran jetzt besser als an Objektorientierter Stil?
    Ich belasse es vorerst bei diesem meinem Ausflug zu Prepared Statements sowie diesen meinem Statement dazu. Mich hat es nicht überzeugt.
    https://www.php.net/manual/de/mysqli...statements.php

  • #2
    Zitat von psoido Beitrag anzeigen
    Diese Prepared Statements werden teils als Heilsbringer angepriesen. Ich habe mir die Sache auch schon einmal angesehen, in der PHP Dokumentation. Doch die ist alles andere als überzeugend. Da werden Prepared Statements mit Objektorientierter Stil und Prozeduraler Stil wild durcheinandergemixt und es bleiben unendlich viele Fragen offen, die auf irgendwelchen Webseiten von irgendwem irgendwie beantwortet werden und am Ende weiß man nicht woran man ist. Ein paar Beispiele.

    Man erstellt also ein Prepare Query:
    $stmt = $mysqli->prepare("INSERT INTO test(id) VALUES (?)");
    der dann anstelle des Platzhalter ? gefüllt werden kann.
    $stmt->bind_param("i", $id);
    zuletzt dann noch ein
    $stmt->execute();
    Wieso füllt man den Platzhalter ? Parameter nicht gleich? Wäre doch weniger Aufwand. Zumal, denn jetzt wird es seltsam und komplex:
    Wie sieht es aus, wenn mehrere Parameter ge-bind-et werden sollen? Da gehts schon los. Die PHP doc löst die Frage, indem sie Objektorientierten Stil verwendet. Feine Sache!
    Was ist mit NULL von PHP nach MySQL? Das scheint simpel zu sein, anscheinend, oder dann doch nicht, weil der bind Typ angegeben werden muss. Hier fehlen mal wieder praktische Beispiele, und es sind nur theoretische zu finden, die fein säuberlich Ziffern anstatt Variablen in Statements verwenden. Wenn ich sowas sehe ist es eh schon aus.
    $mysqli->query("INSERT INTO test(id, label) VALUES (1, 'a')"));
    Ja PHP, ich setze mich hin und fülle jedes Statement manuell aus, 24/7, thas my life! Aber nur, weil ich mir keine kleinen Chinesen leisten kann, die in Servern wohnen und das für mich machen würden.
    Im Internet findet man dann gleich sowas, womit das bind als deprecated eingestuft werden kann, weil mans eh nicht braucht.
    $stmt = $mysqli->prepare("INSERT INTO login(`name`,`password`,`email`,`sex`,`city`) VALUES(?,?,?,?,?)");
    $stmt->execute([$name, $pass, $email, $sex, $city]);
    Da fehlt dann auch arbeitserleichternd die Angabe eines Typs. Feine Sache! Nur, was ist daran jetzt besser als an Objektorientierter Stil?
    Ich belasse es vorerst bei diesem meinem Ausflug zu Prepared Statements sowie diesen meinem Statement dazu. Mich hat es nicht überzeugt.
    https://www.php.net/manual/de/mysqli...statements.php
    Moin also generell bei Prepared Statements, da wird das SQL Query an die Datebank schon vorher gesendet und die Datenbank speichert das SQL ab und weiß dass im nächsten Schritt Parameter dazu kommen.

    Die Datenbank kennt auch schon die Platzhalter und die Datenbank kümmert sich von alleine darum was jetzt ein parameter und was nicht ist.

    Das Problem ist dass mysqli_real_escape_string nicht ausreicht, du kannst auch UTF-8 sonderzeichen in deine Eingabefelder einpflegen die dann durch das escaping rausgehen und deine SQL Anfragen werden dadurch offen.

    Was ist mit NULL? Du kannst einfach eine null übergeben als parameter wo ist das Problem?

    Das mit depricated verstehe ich nicht.. wieso soll $stm->execute depricated sein? ich finde es ist sogar die bessere Variante als mit bind_param zu arbeiten. bind_param ist tatsächlich eine grütze weil dort mit referenzen gearbeitet wird und dadurch durchaus Fehler passieren können.


    In PDO wurde das wesentlich besser gelöst wiel du die Platzhalter bennen kannst

    PHP-Code:
    $statment $pdo->prepare("INSERT INTO login(`name`,`password`,`email`,`sex`,`city`) VALUES(:name,:password,:email,:sex,:city)");
    $statement->execute([
    'name'=>$name,
    'password'=>$password,
    //..usw
    ]); 
    und einige Deiner Aussagen sind irgendwie komisch

    "Feine Sache! Nur, was ist daran jetzt besser als an Objektorientierter Stil?"

    das war der OOP Stiel.

    "Ja PHP, ich setze mich hin und fülle jedes Statement manuell aus, 24/7, thas my life! Aber nur, weil ich mir keine kleinen Chinesen leisten kann, die in Servern wohnen und das für mich machen würden."
    Wtf? du kannst auch query nutzen, nur wie gesagt escapen ist nicht so sicher wie du denkst.

    ich habe mir deshalb das angewohnt die ganze zeit ein prepared statement zu nutzen
    apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

    Kommentar


    • #3
      Zitat von BlackScorp Beitrag anzeigen
      Das mit depricated verstehe ich nicht.. wieso soll $stm->execute depricated sein? ich finde es ist sogar die bessere Variante als mit bind_param zu arbeiten. bind_param ist tatsächlich eine grütze weil dort mit referenzen gearbeitet wird und dadurch durchaus Fehler passieren können.
      Missverständnis! Dann bist du ja auf meiner Seite. Lies nochmal genau was ich dazu geschrieben habe. "bind is deprecated."
      Dann ist also die execute() Version die praktischere und somit wird die Sache einfacher und sicherer? Muss es bei execute() immer ein Array sein? Die Reihenfolge muss sicherlich passen, insbesondere, wenn man das Array vorher erstellt und dann nur eine Array-Variable übergibt.

      Wie viel Sinn ergibt ein SELECT bei Prepared Statements? Der Aufwand steht ja fast im gleichen Verhältnis zu Objektorientierer Stil. Wegen Sicherheitsbedenken wird das wohl nicht überzeugen?
      $stmt = $mysqli->prepare("SELECT id, label FROM test WHERE id = 1");
      $stmt->execute();
      $res = $stmt->get_result();
      $row = $res->fetch_assoc();
      printf("id = %s (%s)\n", $row['id'], gettype($row['id']));

      Kommentar


      • #4
        Ich glaube du bist gerade einfach nur wütend und vermischt hier ein paar Sachen
        Zitat von psoido Beitrag anzeigen
        Missverständnis! Dann bist du ja auf meiner Seite. Lies nochmal genau was ich dazu geschrieben habe. "bind is deprecated."
        Wo steht das?
        https://www.php.net/manual/de/mysqli...bind-param.php weder hier noch https://www.php.net/manual/de/mysqli...ind-result.php sehe ich irgendwo depricated.

        Zitat von psoido Beitrag anzeigen
        Dann ist also die execute() Version die praktischere und somit wird die Sache einfacher und sicherer? Muss es bei execute() immer ein Array sein? Die Reihenfolge muss sicherlich passen, insbesondere, wenn man das Array vorher erstellt und dann nur eine
        Ja weil du bei bind_param und bind_results mit referenzen arbeitest.

        $stmt->bind_param('i',$foo);

        wenn jetzt zwischen bind_param und execute irgendwas passiert wodurch die variable verändert wird, hast du einen falschen Wert in der Datenbank.


        $stmt->bind_param('i',$this->foo);
        $this->machIrgendwas();//hier wird foo warum uach immer aus versehen verändert
        $stmt->execute(); //nutzt das veränderte foo

        bei execute nutzt du keine referenzen sondern übergist die parameter und hast somit den letzten wert und kannst es besser debuggen. Und ja es muss immer ein Array sein und ja du musst auf die Reihnfolge aufpassen, deshalb sage ich dass PDO das besser gemacht hat, weil du platzhalter bennen kannst und musst nicht mit Fragezeichen hantieren.
        [/QUOTE]

        Zitat von psoido Beitrag anzeigen
        Wie viel Sinn ergibt ein SELECT bei Prepared Statements? Der Aufwand steht ja fast im gleichen Verhältnis zu Objektorientierer Stil. Wegen Sicherheitsbedenken wird das wohl nicht überzeugen?
        Wenn dich Sicherheitsbedenken nicht überzeugen dann kann ich dir nicht weiterhelfen.. aber Performance kann dich vielleicht überzeugen. Wenn du zum Beispiel mehrere Daten verändern willst in der Datenbank

        PHP-Code:
        $sql ="UPDATE foo SET bar=?,foobar=? WHERE id=?";
        $stmt $mysqli->prepare($sql);
        foreach(
        $data as $row){
        $stmt->execute($row); //$row ist ein array

        du hast nur ein SQL an die Datenbank geschickt statt mit dem query dann X Sql queries.


        Zitat von psoido Beitrag anzeigen
        $stmt = $mysqli->prepare("SELECT id, label FROM test WHERE id = ?");
        $stmt->execute([$id]);
        $res = $stmt->get_result();
        $row = $res->fetch_assoc();
        printf("id = %s (%s)\n", $row['id'], gettype($row['id']));
        jetzt habe ich deinen code gefixt.



        Zum Thema AUfwand verstehe ich auch nicht was du meinst. Kein Mensch schriebt 1000 Mal den gleichen QUery. irgendwann wird man ja bescheuert dabei. Du erstellst dir eine Klasse die dir Daten holt, da erstellst du dein SQL query ein Mal und dann wars das.

        Wenn du mehrfach gleiche SQL queries an vielen stellen verwendest, dann ist es ein Design Fehler
        apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

        Kommentar


        • #5
          Hey BlackScorp, du nutzt ja auch jede Gelegenheit für ein Missverständis.
          "bind is deprecated." → "Wo steht das?"→ In meinem Beitrag, von mir verfasst!
          "jetzt habe ich deinen code gefixt." → das ist Code aus der PHP Doc.

          Ich sehe da Uneindeutigkeiten bei der Übergabe eines Arrays als Variable bei execute() bezüglich dem WHERE. Gibt es da keine Möglichkeit das WHERE separat zu bestimmen? Also alles in ein Array packen, sowohl Werte als auch WHERES finde ich seltsam. Ich finde die ganze Angelegenheit sowieso seltsam. Wäre das nicht viel praktischer:
          PHP-Code:
          $stmt $mysqli->prepare(`table`);

          $arraywhere["status"] = $status;
          $arraywhere["name"] = $name;
          $stmt->where($arraywhere);
          $arrayvalue["city"] = $city;
          $stmt->execute($arrayvalue);

          $arraywhere["id"] = $id;
          $stmt->where($arraywhere);
          $arrayvalue["name"] = $name;
          $arrayvalue["email"] = $email;
          $stmt->execute($arrayvalue); 
          Nur so eine Idee!

          Wegen dem Aufwand. Es ist doch auch mit herkömmlichen Query-String möglich diesen vor einem Loop als mehrdimensionales Array / Objekt zu definieren und dann in einem Loop beliebig zu befüllen sowie letztendlich als implode() an die Database zu senden. Muss ich das als Beispiel coden? Das kann sich doch jeder selber denken. Nur die Sache mit dem Wegfall von real_escape_string() scheint bei Prepared Statements als einziges zu überzeugen. Perfekt ist es jedenfalls dennoch nicht.

          Kommentar


          • #6
            Zitat von psoido Beitrag anzeigen

            $stmt = $mysqli->prepare("SELECT id, label FROM test WHERE id = 1");
            $stmt->execute();
            $res = $stmt->get_result();
            $row = $res->fetch_assoc();
            printf("id = %s (%s)\n", $row['id'], gettype($row['id']));
            An dieser Stelle kannst du dir das Prepared Statement sparen, weil es ja keinen Parameter gibt.
            Wenn die 1 aus der Where-Klausel ein Parameter wäre und der Code zum Beispiel so aussehen würde:
            PHP-Code:
            $val $_POST['number'];
            $stmt $mysqli->prepare("SELECT id, label FROM test WHERE id = $val");
            $stmt->execute(); 
            Wäre der Code trotz Prepared Statements unsicher, weil der Wert direkt in das SQL eingefügt wurde und beim Parse-Vorgang am Datenbankserver Dinge beeinflussen kann.


            PHP-Code:
            $val $_POST['number'];
            $stmt $mysqli->prepare("SELECT id, label FROM test WHERE id = ?"); 
            (Den Bind-Quatsch mal übersprungen weil ich mysqlli nicht nutze.)
            So müsste es aussehen, damit der Parameter sicher an die Datenbank gesendet wird.

            Wie viel Sinn ergibt ein SELECT bei Prepared Statements?
            Genauso viel wie bei Update-, Delete- oder Insert-Statements. Es geht darum die Parameter sicher zu übergeben und SQL-Injections zu verhindern.
            Wenn du "feste Statements" (wie oben mit "id = 1") nutzt, dann brauchst du keinen Prepare-Vorgang. Sobald der Parameter durch eine Variable (oder auf eine andere Art dynamisch) befüllt wird schon.
            [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
            [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

            Kommentar


            • #7
              Zitat von VPh Beitrag anzeigen
              (Den Bind-Quatsch mal übersprungen weil ich mysqlli nicht nutze.)
              Schön für dich, doch für mich, und eventuell andere, wäre es sehr hilfreich, wenn du bitte mitteilen könntest, wie du es denn nun machst. Also praktische Beispiele anstatt Theorie, wie zB diese 1 im prepare() in der PHP doc! Damit kann keiner was anfangen.

              Eine Frage bei dem Auslassen von bind_param() und nur Nutzen von execute() wäre, wie denn die Values im Array gestalten sein müssen. Das betrifft wieder den Variablen-Typ sowie PHP NULL zu MySQL NULL übergeben. Ist es da egal ob eine Variable mit Integer, Float und Double in Quotes stehen und zB NULL ohne? Und wie ist es mit einer Variable mit String? Kann die ohne Singlequotes übergeben werden? Die Frage wäre, ob eine Variable mit String in execute() explizit nochmals in Singlequotes übergeben werden muss, oder ob das nur bei der "alten" Version nötig war?


              Kommentar


              • #8
                Ich krieg die Krise! Wieso sagt keiner was?
                https://www.php.net/manual/de/pdo.pr...statements.php
                und ich denke das ist gemeint:
                https://www.php.net/manual/de/mysqli...statements.php
                ...

                Kommentar


                • #9
                  ... und das selbe Dilemma. Eine Doc mit manuell befüllten Statements... Steinzeit...

                  // eine Zeile einfügen
                  $name = 'one';
                  $value = 1;


                  Wie sieht die Sache aus bei der Verwendung von Variablen? So etwa?

                  // eine Zeile einfügen
                  $name = "'" . $var["one"] . "'";
                  $value = $var[1];


                  Und wieso meckert PHP nicht, wenn eine Variable schon vor Existenz verwendet wird (in bind_param())?
                  $stmt->bindParam(1, $name);
                  $stmt->bindParam(2, $value);

                  Weil bind_param() eine Function ist?

                  Kommentar


                  • #10
                    Bei PDO kannst du an execute einfach ein Array übergeben in dem die Parameter stehen, ohne irgendwelche der Werte extra behandeln zu müssen.
                    Bei mysqli... keine Ahnung. Es ist den Aufwand auch nicht wert sich über die mysqli-API Gedanken zu machen, sie ist in der Handhabung bedeutend umständlicher und vom Funktionsumfang eingeschränkter.

                    Ist es da egal ob eine Variable mit Integer, Float und Double in Quotes stehen
                    ?
                    Meinst du im Template zum SQL-Statement? Da braucht es keine Quotes.
                    PHP-Code:
                    $statement $pdo->prepare('SELECT firstname, lastname FROM user WHERE email = ? OR userId = ?');
                    $statement->execute([$email$id]); 
                    [edit, nächster Post]
                    Wie sieht die Sache aus bei der Verwendung von Variablen? So etwa?

                    // eine Zeile einfügen
                    $name = "'" . $var["one"] . "'";
                    $value = $var[1];
                    Was soll damit sein? $name ist im Endeffekt ein ganz normaler String und $value kann irgendwas sein. Die werden auch einfach als Parameter übergeben. Du siehst Sonderfälle wo keine sind.

                    Und wieso meckert PHP nicht, wenn eine Variable schon vor Existenz verwendet wird (in bind_param())?
                    $stmt->bindParam(1, $name);
                    $stmt->bindParam(2, $value);
                    Weil bind_param() eine Function ist?
                    Weil bindParam mit den Referenzen zu den Variablen und nicht direkt mit den Werten der Variablen arbeitet.
                    [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
                    [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

                    Kommentar


                    • #11
                      Zitat von psoido Beitrag anzeigen
                      "bind is deprecated." → "Wo steht das?"→ In meinem Beitrag, von mir verfasst!
                      wenn ich deprecated höre, dann gehe ich davon aus dass es von PHP Deprecated ist, in deinem Beitrag konnte ich das nirgends rauslesen und in der dokumentation steht nichts von depricated..

                      Zitat von psoido Beitrag anzeigen
                      "jetzt habe ich deinen code gefixt." → das ist Code aus der PHP Doc.
                      dein code hat keinen Sinn gemacht, deswegen habe ich ihn gefixt.
                      Zitat von psoido Beitrag anzeigen
                      Ich sehe da Uneindeutigkeiten bei der Übergabe eines Arrays als Variable bei execute() bezüglich dem WHERE. Gibt es da keine Möglichkeit das WHERE separat zu bestimmen? Also alles in ein Array packen, sowohl Werte als auch WHERES finde ich
                      seltsam. Ich finde die ganze Angelegenheit sowieso seltsam. Wäre das nicht viel praktischer:
                      Das eine ist SQL Query zusammensetzen, das andere ist parameter übergeben.

                      NATÜRLICH kannst du mit implode usw.

                      Zitat von psoido Beitrag anzeigen

                      Wegen dem Aufwand. Es ist doch auch mit herkömmlichen Query-String möglich diesen vor einem Loop als mehrdimensionales Array / Objekt zu definieren und dann in einem Loop beliebig zu befüllen sowie letztendlich als implode() an die Database zu senden. Muss ich das als Beispiel coden?
                      Ja bitte, ich habe keine Ahnung was du meinst, herumhantieren mit einem array und dann ein Implode zu machen ist nur möglich bei geringen Datenstäzen. Sobald dein Array größer wird hast du gleich mal deinen Speicher voll gemacht.
                      Zitat von psoido Beitrag anzeigen
                      Nur die Sache mit dem Wegfall von real_escape_string() scheint bei Prepared Statements als einziges zu überzeugen. Perfekt ist es jedenfalls dennoch nicht.
                      Du nutzt auch mysqli, NATÜRLICH ist es nicht perfekt und keiner will damit arbeiten...
                      apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

                      Kommentar


                      • #12
                        Hellbringer hat es ja schon angedeutet, dass die Sache mit Variable in Singlequotes oder nicht in Singlequotes im Query-String hinfällig wäre. Ich frag nur nochmal nach, bevor ...

                        Also ich würde eh die Version mit :named bevorzugen, allein der Übersichtlichkeit halber. In der PHP Doc steht da allerdings wieder was verwirrendes. Also das Folgende würde mir taugen. Geht das auch mit auslassen von ", array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY)" und Array als Variable mit Values?

                        $sql = 'SELECT name, colour, calories
                        FROM fruit
                        WHERE calories < :calories AND colour = :colour'
                        ;
                        $sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
                        $sth->execute(array(':calories' => 150, ':colour' => 'red'));
                        $red = $sth->fetchAll();
                        $sth->execute(array(':calories' => 175, ':colour' => 'yellow'));
                        $yellow = $sth->fetchAll();

                        Von hier: https://www.php.net/manual/de/pdo.pr...epare-examples

                        Also so:

                        $sql = 'SELECT name, colour, calories
                        FROM fruit
                        WHERE calories < :calories AND colour = :colour'
                        ;
                        $sth = $dbh->prepare($sql);

                        $sthquery = array(
                        ':calories' => $value[150], // int(150)
                        ':colour' => $value['red'] // string('red')
                        );

                        $sth->execute($sthquery);
                        $red = $sth->fetchAll();
                        unset($sthquery);

                        $sthquery = array(
                        ':calories' => $value[175], // int(150)
                        ':colour' => $value['yellow'] // string('yellow')
                        );

                        $sth->execute();
                        $yellow = $sth->fetchAll();

                        unset($sthquery);

                        Und natürlich die NULL Frage, wie ist es mit:

                        $sthquery = array(
                        ':calories' => $value["NULL"], // NULL
                        );


                        Oder gibt es daran etwas auszusetzen oder zu verbessern?

                        Kommentar


                        • #13
                          Jaja, ihr seid mir schon so ein paar Tastaturhelden. Verwende PDO Prepared Statement und sende bei einem database connection error Username und Passwort in Klartext übers Internet! Alles klar! Danke für den Hinweis!

                          Total genial. Erinnert mich an Menalto/Gallery3, die in einen Global Array Username und Password vom Login neben jede Menge anderen Kram fürs Frontend gepackt hatten. Bei jedem var_dump() ... Aber das war ja nicht deren einziges Problem...

                          Kommentar


                          • #14
                            Sorry, bist du high?
                            [COLOR=#A9A9A9]Relax, you're doing fine.[/COLOR]
                            [URL="http://php.net/"]RTFM[/URL] | [URL="http://php-de.github.io/"]php.de Wissenssammlung[/URL] | [URL="http://use-the-index-luke.com/de"]Datenbankindizes[/URL] | [URL="https://www.php.de/forum/webentwicklung/datenbanken/111631-bild-aus-datenbank-auslesen?p=1209079#post1209079"]Dateien in der DB?[/URL]

                            Kommentar


                            • #15
                              PHP und die Datenbank befinden sich so gut wie immer auf dem selben Server. Da gehen also keine Verbindungsinformationen zur DB übers Internet !

                              Kommentar

                              Lädt...
                              X