Verwendung von "mysql_real_escape_string()" / standard PHP/SQL-Syntax



  • Hi,
    Wie verwende ich "mysql_real_escape_string()" richtig bzw. wie sollte ich es verwenden? So wie ich das verstanden habe, brauche ich es nur direkt in der sql-Anfrage verwenden, aber die Beispiele auf php.net sind da nicht sehr aufschlussreich. Zudem würde ich mal gerne wissen (ich habe jetzt ca. 5 verschiedene Methoden gesehen), wie man SQL-Anfragen von der Syntax(in Verbindung mit PHP) her "richtig" schreibt. (Scheint wohl alles irgendwie zu gehen, aber was ist der allgemeine Standard?)

    Hier erstmal der Code, wie ich es bisher dachte, es sei richtig, leider liefert die Anfrage in der SQL-Datenbank immer false bzw. nicht einen Datensatz zurück. Ihr könnt den Code einfach kopieren/editieren, wie ihr meint er sei richtig 🙂

    //Verbindung erfolgreich zur SQL Datenbank hergestellt
    $SQL = "SELECT 
              Punkt1, //Wie siehts mit Umlauten bzw. "Sonderzeichen" wie ".,-" aus?
    	      Punkt2,
    	      Punkt3,
    	      Punkt4 
    	  FROM 
    	      Blub 
    	  WHERE 
    	      Name = '".mysql_real_escape_string($_POST['Name'])."'  //Mit "," trennen?
    	      AND Passwort = '".mysql_real_escape_string($_POST['Passwort'])."'
    	      AND ID = '".mysql_real_escape_string($_POST['ID'])."';";
    $SQL_Query = mysql_query($SQL);
    if (!$SQL_Query || mysql_num_rows($SQL_Query) != 1)
    {
        header ("location: index.php?Error=1");
        exit;
    }
    

    So,wie gesagt, warum findet mein PHP Interpretert da nichts(Einträge sind vorhanden) und wie sieht der allgemeine Standard aus?

    Danke



  • Hallo,

    was mir gleich als allererstes Auffällt: Was hat dich gestochen, PHP-Kommentare in den SQL-Query zu schreiben? 😮

    Abgesehen davon wundert mich weniger, warum du keine Ergebnisse vom SQL-Daemeon zurück bekommst, als vielmehr, warum dir PHP keinen Parse Error ausspuckt!? 😉

    Ansonsten sieht die Verwendung von der escape-Funktion schon ganz ordentlic aus. In Größeren Projekten würde man sich sicherlich einen Wrapper basteln, aber so ist es erstmal völlig in Ordnung.

    Die Passwortabfrage würde man allerdings haschen, und das Passwort vor allem gehascht in der Datenbank speichern.

    Ansonsten ist dein Zeichenkettenvergleich Case-insensitive. Ein Benutzer mit dem Namen "arny" und dem Passwort "ek" könnte sich also auch als "ARnY" mit dem Passwort "Ek" anmelden. Willst du das verhindern, caste eine der beiden Stringliterale nach BINARY.



  • du hast ein semikolon zuviel. (die query ohne!)

    ."';";
    

    lass dir bitte mal den string mit echo ausgeben, und schau ihn dir genau an.
    alles da? und: leerzeichen drin? oder hängt da was zusammen.

    gruß



  • Naja wo du es sagst fällt mir das mit den Kommentaren auch auf, aber naja 🙂
    PW's werden noch gehasht (hatten wa ja mal besprochen :D)
    Ansonsten hab ich nun den Fehler gefunden.
    Erstmal error_reporting auf E_All und dann habe ich mir noch ein paar mysql_error() Ausgaben zeigen lassen. Im Endeffekt hatte ich (bis auf ein paar Syntax-Fehler) vergessen mich mit einer Datenbank zu verbinden.
    Achso, für alle die es interessiert:
    Laut myPHPAdmin(spuckt er mir in der Form aus^^) müsst der SQL-Befehl so aussenen:

    $SQL = "SELECT 
    	  					`Punkt1`,
    	 				 		`Punkt2`,
    	 				 		`Punkt3`,
    	 				 		`Punkt4` 
    	 				 	FROM 
    	 				 		`Bla` 
    	 				 	WHERE 
    	 				 		`Name` = '".mysql_real_escape_string($_POST['Name'])."'
    	 				 		AND `Passwort` = '".mysql_real_escape_string($_POST['Passwort'])."'
    	 				 		AND `ID` = '".mysql_real_escape_string($_POST['ID'])."'";
    

    (komisch mit dem Einrücken 😮 )



  • Die Einrückung ist bei SQL-Statements egal. Sie wird halt genutzt, um die Query übersichtlich zu formatieren 😉

    Die Backticks (`) lässt du aber besser weg 😉
    Mit ein Grund, warum man das nicht machen sollte, ist, wenn man bedenkt, wofür die Backticks eingeführt wurden: Nämlich um Spalten mit erweiterten Bezeichnungen zu unterstützen. Durch die Backticks kannst du z.Bsp. auch Spalten handhaben, die "Eine sehr merkwürdig benannte Spalte" heißen. Das ist stilistisch und designtechnisch aber äußerst fragwürdig, da die meisten Spalten wohl mit Benennungen wie "userId", "productTitle", "postText" etc. wesentlich sinnvoller und kürzer benannt werden können.

    Der eigentliche Grund, warum ich von den Backticks abraten würde, ist aber die Portabilität! Bei der Wahl der Zeichen zur Begrenzung von Spaltennamen und -aliasen bastelt nämlich jede Datenbank ihren eigenen Brei. Unter MSSQL werden die Bezeichner z.B. nicht in Backticks eingeschlossen, sondern in eckige Klammern. Was tun, wenn du nun ein umfangreiches Projekt von einer Datenbank zur anderen Migrieren möchtest? -> Fatal! Und das selbst, wenn du eine Wrapperklasse verwendest.

    Ergo: Gutes Datenbankdesign entwerfen, sinnvolle und nach Möglichkeit nur aus von ASCII gedeckten Zeichen bestehende Tabellennamen verwenden, keine datenbankspezifischen Extrawürste braten und gut ist.


Anmelden zum Antworten