Nachtzrag zu meinem letzten Posting:

Wenn ich es so mache wie im letzten Posting beschrieben, kommt _überhaupt nichts_ an.

Wenn ich es _so_ mache =>

  
$empfaenger="Jürgen Mustermann-Weiß <j-mustarmann-weiss@example.org>","UTF-8", "Q");  
$betreff=mb_encode_mimeheader("Bitte bestätigen Sie Ihren Gästebucheintrag mailtest5 ","UTF-8", "Q");  
$text="Hänsel und Gretel wünschen sich Hörnchen über alles.";  
$header="";  
$header.="MIME-Version: 1.0\n";  
$header.="Content-type: text/plain; charset=utf-8\n";  
$header.="Content-Transfer-Encoding: 8bit\n";  
$header.="From: Max Mustermann <mustermann@example.com>\n";  
mail ($empfaenger,$betreff,$text,$header, "-fmustermann@example.com");

dann kommt zwar was an, allerdings steht jetzt beim Betreff: Bitte bestätigen Sie Ihren Gästebucheintrag - also VÖLLIGES Chaos, selbiges beim Namen des Empfängers, auch dort eine Falschdarstellung.

Ich stelle fest, je mehr ich versuche, um so weniger klappt es. =(((

Yerf!

Ich kann zwar eigentlich kaum PHP, nur aus ein paar kleineren CMS-Anpassungen und dem was ich hier so mitlese, aber vielleicht kann ich trotzdem (oder gerade deswegen) ein paar Anhaltspunkte geben.

(evtl. kann Jens ja noch ein paar Kommentare dazu geben)

Alle SQL-Statements, nicht nur diese vier, werden gleich behandelt, was den Weg zum DMBS hin betrifft.

Was willst Du mir _damit_ sagen?

Das soll heisen, das an der Stelle, wo du *ein bestimmtes* SQL-Statement verwenden kannst, eigentlich *jedes* Statement möglich ist. Änder doch in deinem Beispiel die Variable $sql die du dem prepare() übergibst einfach entsprechend. Mysqli ist es völlig egal, ob du da einen select, update oder drop table drinnen hast. Einfach etwas damit rumexperimentieren.

Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Nein, das kommt nicht von mysqli oder den prepared statements, die arbeiten völlig transparent. Die Slashes kommen von den Magic-Quotes die scheinbar angeschalten sind. Dies passiert am Anfang des Scripts völlig unabhängig von irgendwelchen Datenbanksachen (und genau das ist auch deren Problem).

Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Zu diesem Zeitpunkt sind die Daten schon "versaut", da musst du schon vorher eingreifen, das komt gleich:

Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern? Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

Du musst kein extra Escaping mehr vornehmen, ja das ist richtig. Allerdings musst du sicherstellen, dass die Magic Quotes ausgeschalten sind oder diese am Anfang des Scriptes händisch rückgängig machen, da sie dir ansonsten die Daten versauen. Ein Problem das erst mit PHP 6 endgültig gelöst sein wird (da fliegen die Dinger raus)

Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

Die Kodierungsangabe ist nicht nur für die Daten, die du der DB übergibst zuständig, sie sagt auch aus, in welcher Kodierung du gerne die Antwort hättest. Die Datenbank ist da flexibel und nimmt notfalls ein umkodieren vor, wenn du die Daten anders haben möchtest, als sie in der Tabelle abgelegt sind.

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:
$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort='.$\_POST['ortsuche'].' ORDER BY id';
$ergebnis = $db->prepare( $sql );

Integriere den Parameter so in dein Statement, wie du das bereits bei 1) getan hast. Du verwendest P.S., also brauchst du keine Daten händisch in das Statement einzubauen.

Wie meinst Du das? BITTE schreib mir doch die Zeile so hin, wie es richtig wäre.

Er meint anstelle von ort='.$\_POST['ortsuche'].' ein ort=? und danach mit bind_param('ssi',$_POST['ortsuche']) arbeiten.

Nur über bind_param wird das Escapen überflüssig, was du händisch in den SQL-String einbaust müsstest du entsprechend bearbeiten.

Super. Weil GENAU DAS war es ja, was ich wissen wollte, weil ich es eben NICHT kann. Und ich finde auch nach 4 Stunden nicht _eine_ Seite im Netz, wo das hergezeigt wird. Ich finde weiterhin nur Seiten, wo man Beispielcodes für das Erstellen von Datensätzen oder für das Anzeigen aller Datensätze einer Tabelle sieht.

$sql = 'UPDATE tabelle1 SET geburtsjahr = ? WHERE name = ?';
 $kommando = $db->prepare($sql);
 $kommando->bind_param('ssi', $_POST['name'], $_POST['geburtsjahr']);
 $kommando->execute();

Ungetestet, sollte aber das Geburtsdatum aller Personen mit dem entsprechenden Namen setzen...

Gruß,

Harlequin

Hallo.

Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Wenn du "Hans" (mit den Anführungszeichen) in dein Formular eingibst, dann sollte in der Datenbank auch "Hans" (mit den Anführunszeichen) gespeichert werden, und nicht "Hans" oder irgendetwas anderes. Du willst ja genau das, was eingegeben wird, auch in der Datenbank haben.

Dass die " um Hans herum escaped werden (d.h. ein \ davor gesetzt wird), liegt an dem PHP-"Feature" Magic Quotes. Die Prepared Statements sorgen nur u.a. dafür, dass die Daten, die du an die Datenbank schickst, auch genauso in der Datenbank ankommen.

Hier geht es jetzt rein um die _Ausgabe_. Natürlich will ich die Stripslashes loswerden davor! Aber deswegen hab ich doch mit nichts Probleme??!

Es ist nur unnötig kompliziert, erst PHP alle " escapen zu lassen und dann ständig aufzupassen und dran zu denken, dass das so ist, und dann auch evtl wieder rückgängig zu machen.
Einfacher ist es, die Magic Quotes gleich ganz auszuschalten, oder ihre Wirkung zu Scriptbeginn global rückgängig zu machen (siehe dazu dedlfix' Link).

Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.

Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Mit Eingabedaten ist gemeint: $_GET, $_POST, etc...

Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern? Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

Sofern du Prepared Statements verwendest, brauchst du dich nicht mehr um SQL-Injection kümmern, unabhängig davon, ob Magic Quotes aktiviert sind oder nicht.

Bei jeglicher Kommunikation mit dem DBMS sollte die Verbindungskodierung ausgehandelt werden, ansonsten wird ein System-Default-Wert verwendet. MySQL kodiert die Felddaten in die Verbindungskodierung um, wenn diese eine andere als die Feldkodierung ist. Das willst du nicht, wenn dein Default-Wert Latin1 ist, denn du willst ja mit UTF-8 weiterarbeiten. Außerdem gehen die Zeichen verloren, die nicht in Latin1 enthalten sind.

Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

Immer, wenn du mit dem DBMS kommunizierst, werden dabei irgendwelche Daten übertragen. Und damit alle Beteiligten wissen, wie diese Daten kodiert (utf-8, etc..) sind,  musst du das halt angeben, ist doch logisch :-)

Tja, wenn ich nur wüßte, wie?

So wie dus weiter oben auch gemacht hast. SQL String mit $stmt = $db->prepare($sql) vorbereiten, dann die Parameter mit $stmt->bind_param() einfügen. Das funktioniert auch bei WHERE. ("... WHERE foo=?")

Das Prinzip ist auch bei diesen beiden Statements kein anderes als bei Nummer 1.

Super. Weil GENAU DAS war es ja, was ich wissen wollte, weil ich es eben NICHT kann.

Du kannst es doch: SQL String vorbereiten, Parameter dranbinden, ausführen, wie oben auch schon.

Ob das SQL jetzt aus "UPDATE bla SET foo=? WHERE baz=?" oder "DELETE FROM bla WHERE baz=?" oder "SELECT foo FROM bla WHERE baz=?" oder "INSERT INTO bla (foo) VALUES (?)" besteht, ist egal. Du musst halt nur immer die passenden Parameter dranbinden.

Servus,
Flo

echo $begrüßung;

Ich nehme an, was Du mir damit sagen willst ist, daß bei der Prozedur mit den prepared Statements keine SQL Injection passieren kann, weil sich das System automatisch um das Escapen kümmert? Das habe ich schon verstanden.

Nicht ganz. Wenn du ein Statement zu Fuß zusammenbaust, bringst du dabei einzufügende Daten in den SQL-Satement-Kontext. Dafür ist eine kontextgerechte Behandlung erforderlich. Bei P.S. gehen Statement und Daten getrennte Wege. Die Daten werden also nicht in das SQL-Statement eingebettet werden, und müssen demzufolge auch nicht dafür behandelt werden.

Auf welche Art und Weise die Übertragung wirklich erfolgt, kann uns egal sein. Die Daten müssen in Rohform an die dafür vorgesehene Funktion übergeben werden und der Rest ist Blackbox.

Ich hab das mit der kontextbezogenen Behandlung schon auf die Ausgaben bezogen. Oder war Deine Antwort anders gemeint?

Du hast aber auch einen Kontextwechsel, wenn du Daten direkt in ein SQL-Statement einfügst.

Alle SQL-Statements, nicht nur diese vier, werden gleich behandelt, was den Weg zum DMBS hin betrifft.
Was willst Du mir _damit_ sagen?

Es gibt keinen Unterschied ob du einen Wert in ein SELECT- oder INSERT- oder Sonstwas-Statement einfügst. Ebenso müssen für alle Arten von Statements die Übertragungsbedingungen auf gleiche Weise berücksichtigt werden, was hier heißen soll, dass die Kodierung immer eine Rolle spielt und explizit ausgehandelt werden sollte.

2. Alle Datensätze der Tabelle ausgeben mit mysqli:
      echo "<p>".htmlspecialchars(stripslashes($id))." ==> ".htmlspecialchars(stripslashes($name))." aus ".htmlspecialchars(stripslashes($ort))." ist ".htmlspecialchars(stripslashes($geburtsjahr))."geboren.</p>\n";
   Wenn du hier stripslashes() verwendest, weil du sonst ungewollte \ in der Ausgabe hast, dann hast du ein Problem mit den Magic Quotes, das du aber an ganz anderer Stelle lösen musst.
   Ich verstehe Dich einfach nicht!!! Wenn man über das Formular zB beim Namen Hans eingibt und davor und danach ein Anführungszeichen schreibt, dann landet das als "Hans" in der DB. Aber nicht, weil ich mich darum gekümmert habe, sondern weil das durch das mysqli und den prepared Statements automatisch passiert, oder??

Du hast hier einen Nebenkriegsschauplatz, der durch das PHP-Feature Magic Quotes entsteht.

Hier geht es jetzt rein um die _Ausgabe_. Natürlich will ich die Stripslashes loswerden davor! Aber deswegen hab ich doch mit nichts Probleme??!

Na doch, dass es ein Problem ist, zeigt sich daran, dass du es behandeln musst, weil du sonst ungewollte Backslashes bekommst. Das Problem hätte nicht sein müssen, wenn das Feature Magic Quotes dir es nicht stillschweigend aufgetischt hätte.

Magic Quotes waren gedacht, um SQL-Injection-Probleme zu lösen. Doch dieses Feature wirkt auf alle Eingabedaten, nicht nur auf die, die in ein SQL-Statement eingebaut werden und auch auf die, die aufgrund von P.S. aus Prinzip kein SQL-Injection-Problem haben.
Hier geht es doch um keine Eingabedaten, hier gebe ich was _aus_!

Ja, das Problem entstand aber schon, offensichtlich ohne von dir bemerkt zu werden, beim Einfügen der Daten in das DBMS. Magic Quotes wollte für Sicherheit sorgen, hat aber stattdessen deine Daten ungewollt und unnötig verändert.

Wenn bei dir die Magic Quotes eingeschaltet sind, bekommst du nun fehlerhafte Daten in dein DBMS, weil der \ als ganz normales Zeichen angesehen wird. Sorge dafür, dass die Magic Quotes generell deaktiviert oder einmalig am Script-Anfang deren Auswirkungen rückgängig gemacht werden.
Mir wurde doch letztens extra erklärt, wenn ich diese moderne Form (also das mysqli) nehme, dann brauche ich keine Angst vor SQL Injections haben und mich auch nicht davor schützen, weil das das System automatisch macht. Und jetzt muß ich mich _doch_ plötzlich wieder um Dinge wie Magic Quotes kümmern?

Ein eingeschaltetes Magic Quotes behandelt vorsorglich vor dem Scriptstart sämtliche GPC-Daten (GET, POST, Cookie) mit addslashes(). Das ist (nicht nur) in deinem Fall kontraproduktiv, weil du dich selbst darum kümmerst, beziehungsweise es nicht brauchst, weil das Injection-Problem mit P.S. nicht relevant ist.

Dachte, das betrifft mich nur, wenn ich die althergebrachten Methoden verwende?

M.Q. interessiert sich nicht dafür, ob du P.S. verwendest, oder die Daten gar nicht in einen SQL-Kontext gelangen. Du brauchst M.Q.s nicht, also deaktiviere sie generell oder entferne nach dem Scriptstart die überflüssigen Zeichen.

Bei jeglicher Kommunikation mit dem DBMS sollte die Verbindungskodierung ausgehandelt werden, ansonsten wird ein System-Default-Wert verwendet. MySQL kodiert die Felddaten in die Verbindungskodierung um, wenn diese eine andere als die Feldkodierung ist. Das willst du nicht, wenn dein Default-Wert Latin1 ist, denn du willst ja mit UTF-8 weiterarbeiten. Außerdem gehen die Zeichen verloren, die nicht in Latin1 enthalten sind.
Aha. Bin zwar jetzt schon so verwirrt, daß ich gar nichts mehr verstehe, aber ich gebe es wieder dazu, lasse das also IMMER dabei.

Die Verbindungskodierungskonfiguration sorgt einerseits dafür, dass MySQL deine Statements und (P.S.-)Daten mit der angegebenen Kodierung interpretiert, andererseits, dass es seine Rückgabewerte in dieser Kodierung ausliefert.

2B) Ausgabe von Datensätzen unter einer Bedingung mit mysqli:
$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort='.$\_POST['ortsuche'].' ORDER BY id';
$ergebnis = $db->prepare( $sql );
Integriere den Parameter so in dein Statement, wie du das bereits bei 1) getan hast. Du verwendest P.S., also brauchst du keine Daten händisch in das Statement einzubauen.
Wie meinst Du das? BITTE schreib mir doch die Zeile so hin, wie es richtig wäre.

$sql = 'SELECT id, name, ort, geburtsjahr FROM tabelle1 WHERE ort=? ORDER BY id';
  $kommando = $db->prepare($sql);
  $kommando->bind_param('s', $_POST['ortsuche']);
  // execute() usw.

Du möchtest wechselnde Daten in ein SQL-Statement einfügen. Es gibt keinen Unterschied zwischen Daten, die in die DB eingetragen werden sollen und solchen, die ein Suchkriterium darstellen. Für alle veränderlichen Daten kannst du einen Platzhalter notieren und anschließend eine Variablen-Bindung vornehmen.

echo "$verabschiedung $name";