|
|
|
|
|
PHP-Panschen für Anfänger
|
Morgen,
Ich hätte heute gerne mal eine theoretische Frage diskutiert, auf die ich auch nach mehrtägigem Grübeln keine sinnvolle Antwort finden konnte. Konkret geht es um meine Toolsuche, in theoretischem Umfang geht es aber auch um Seiten wie diese hier.
Wie bringe ich - wenn es ums escapen geht - sowohl Usability als auch Spam-Sicherheit unter einen Hut?
Bezüglich des Datenbankescapens bin ich, denke ich, auf der sicheren Seite: Ich lese jeweils aus, ob Magic Quotes gesetzt ist, wenn ja, kommen und gehen die Daten ohne weiteres aus der DB, ansonsten kommt add-/stripslashes() zum Einsatz.
Nun aber bei HTML: Technisch gesehen gilt, glaube ich, das Prinzip, dass Daten möglichst unverändert in eine DB kommen sollten und erst bei der Ausgabe verändert werden sollten. Daran habe ich mich jedenfalls jeweils gehalten. Was aber auf dem Weg in die DB? Ich habe eine Eingabemaske, die eine Reihe von Daten verlangt. Ist alles in Ordnung gehen sie in die DB und beim Füllen des Templates werden sie dann mit htmlentities behandelt. So weit so gut.
Wenn nun aber ein User nicht alle Felder sauber ausgefüllt hat kriegt er die Eingabemaske noch einmal zu sehen und hier beginnt das Problem: Die Daten die er bereits eingegeben hat, sollen wieder in der Maske erscheinen. Damit die Maske nicht zerhauen wird, muss ich nun aber bereits hier mit htmlentities dahinter. Und das heisst, dass die Daten dann bereits hier nicht mehr so aussehen, wie sie sollten und auch später nicht mehr, da sie ja schon escaped in die DB gelangen.
Wie gehe ich also am besten vor, um Kosmetik und Schutz vor Witzbolden gleichzeitig zu haben?
(Ich hoffe, ich habe mich einigermassen verständlich ausgedrückt.)
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TheRealPlextor am 30.03.2008 15:28]
|
|
|
|
|
|
|
|
|
Wenn ich dich richtig verstanden habe, gehts dir darum die Daten die fehlerhaft sind im Formular genauso stehen zu lassen wie sie eingetragen worden sind?
Ich überprüfe mit einer $error Variable ob alle Eingaben gültig sind, wenn das nicht der Fall ist, ist $error eben true und das Formular wird erneut ausgegeben.
Die input Felder werden dann einfach mit $_POST["xx"] ausgefüllt.
Wenn alle Eingaben gültig sind, dann wird das Zeug escaped (mysql_real_escape_string()  ) und in die Datenbank geschrieben.
|
|
|
|
|
|
|
|
|
|
|
Es geht wohl eher darum, wenn ein User so lustige Eingaben wie " macht, diese mit htmlentities in die Inputfelder geschrieben werden muessen, da sie sonst das Formular zerstoeren.
Was spricht denn gegen html_entity_decode , wenn die Daten erst beim zweiten Absenden korrekt sind?
|
|
|
|
|
|
|
|
|
|
|
Plexi mag ja kein Javascript aber dafür isses doch super :x
| |
| PHP: |
<input type="text" id="d" />
<script>
document.getElementById("d").value="\"";
// oder halt:
document.getElementById("d").value="\<?=$_POST["d"]?>";
</script>
|
|
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Teufel am 30.03.2008 15:46]
|
|
|
|
|
|
|
|
|
| | Zitat von Zensiert
Es geht wohl eher darum, wenn ein User so lustige Eingaben wie " macht, diese mit htmlentities in die Inputfelder geschrieben werden muessen, da sie sonst das Formular zerstoeren.
Was spricht denn gegen html_entity_decode , wenn die Daten erst beim zweiten Absenden korrekt sind?
| |
Auch wenn die Chance, dass es wirklich mal passiert eins zu einer Million ist, aber es könnte ja sein, dass der User schreiben will, dass er ein Tool gefunden hat, welches automatische escapes macht und deshalb "aus & & macht". Hier im Forum muss ich das auch bereits selber von Hand escapen, wenn ich es so angezeigt haben will. Und da ich nicht zuverlässig abfangen kann, ob der Inhalt eines Feldes das erste oder schon das zweite Mal durch selbiges gegangen ist, kann die Funktion den Inhalt schreddern. Und ich suche halt nach einer Möglichkeit, die den Text wirklich so lässt, wie ihn der User gemeint hat, aber ihn immer schön escaped, wenn er schaden könnte.
Oder anders ausgedrückt: Wie kann man in diesem Forum hier den "\"-Preview-Bug verhindern.
@Teufel: Mir ist nicht ganz klar, was dein Script erreichen soll, ausser die Forms über einen Umweg zu füllen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von TheRealPlextor am 30.03.2008 16:05]
|
|
|
|
|
|
|
|
|
Damit kannst du " innerhalb von einem Input Feld als Value eingeben.
Geht nicht per HTML. // doch
Ansonsten würde ich dir einfach raten die Strings so zu nehmen wie sie sind und per str_replace(Array(), Array(), $_POST["name"]) nur die Sachen zu filtern die nötig sind...
Aber ich glaube du meinst etwas anderes 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Teufel am 30.03.2008 19:49]
|
|
|
|
|
|
|
|
Ich meine in der Tat etwas anderes.
Also versuchen wir es doch mal mit einem Beispiel:
Ein User schreibt mir ein Tool in die Sammlung und mit der Beschreibung "Dieses Tool ersetzt automatisch & durch &."
Variante 1 - Er hat alles korrekt ausgefüllt:
Die Beschreibung landet in der DB. Und wenn sich ein User dann das Tool angucken geht, wird durch htmlentities() aus dieser Beschreibung "Dieses Tool ersetzt automatisch & durch &amp;.". Dies ist richtig so, weil es durch den Browser wieder so dargestellt wird, dass es aussieht, wie der User es wollte.
Variante 2 - Der User hat noch ein Feld vergessen:
Die Daten werden nun wieder in die Eingabemaske gefüllt. Dabei müssen sie aber bereits hier escapet werden, weil es sonst vorkommen kann, dass die Eingabemaske auseinandergerissen wird. Der User sieht alles korrekt, weil auch hier das "Dieses Tool ersetzt automatisch & durch &amp;." vom Browser so interpretiert wird, dass es aussieht, wie es der User eingegeben hat.
Wenn er nun aber das Tool abschickt, kommt es so in die DB und beim Ausgeben wird es escaped - schon wieder! Damit sind wir bei "Dieses Tool ersetzt automatisch &amp; durch &amp;amp;." und das ist dann sicher nicht mehr, was der User wollte.
Variante 3 - Jeden Beitrag vor dem Eintrag in die DB html-strippen
Wenn ich nun versuche dem Vorzubeugen und so zuviel escapedes präventiv rück zu escapen, wird aus dem Beitrag "Dieses Tool ersetzt automatisch & durch &." und das will der User auch wieder nicht.
Folge: Was muss ich tun, damit immer dann - aber auch nur dann - escaped oder zurück escaped wird, wenn es auch wirklich nötig ist?
|
|
|
|
|
|
|
|
|
|
|
|
wenn es dir um eingabemasken geht: muss man da auf irgendwas anderes als " achten? mir ist so, als würde da sowieso plain text angezeigt. (ich spreche von input-feldern.)
|
|
|
|
|
|
|
|
|
|
|
| | oli, 30.03.2008 19:42:54:
http://oli.homeunix.net/test.php
oli, 19:43:02:
schreib da && rein und schick ab
oli, 19:43:10:
es wird jedes mal htmlentities drübergezogen
oli, 19:43:16:
aber du kannst sooft abschicken wie du willst
oli, 19:43:42:
nach seiner theorie würde nach dem ersten mal draus werden:
&
dann &amp; | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Teufel am 30.03.2008 19:46]
|
|
|
|
|
|
|
|
|
| | Zitat von rABBI
wenn es dir um eingabemasken geht: muss man da auf irgendwas anderes als " achten? mir ist so, als würde da sowieso plain text angezeigt. (ich spreche von input-feldern.)
| |
Bei Input-Felder ist es wirklich nur " (und für mich ', da ich die anstelle von " benutze). Aber bei Textarea-Felder ist es alles andere, was noch einen Tag darstellen kann.
@Teufel: Danke für die Klärung, ich dachte, das würde strikt immer die Zeichen ersetzen.
Das würde dann aber dennoch heissen, dass mein Beispiel - direkt durch ein HTML-abstrippen gejagt ohne vorher nochmal durch die Maske zu gehen - trotzdemm immer noch aus "& und &" "& und &" machen würde.
|
|
|
|
|
|
|
|
|
|
|
Ich seh das Problem ehrlich gesagt nicht.
1. Beim in die DB schreiben quotes escapen (mit der mysql_real_bla() oder halt per DB Abstraktionsdingens)
2. Beim Anzeigen im Browser die HTML Entities encoden.
Dadurch sollten sich eigentlich keine Probleme ergeben. Ich spiel nochmal dein Beispiel, mit den & und & durch:
1. Eingabe "Dieses Tool ersetzt automatisch & durch &."
2. Fehler aus irgend nem Grund, wird nicht in die DB geschrieben
3. Ausgabe der POST Variable im Browser (entities werden escaped):
"Dieses Tool ersetzt automatisch & durch &amp;."
Dieser String steht nun so im Quelltext, was völlig ok ist, da es dem User ja als "Dieses Tool ersetzt automatisch & durch &." angezeigt wird. Der Browser sumitted auch "Dieses Tool ersetzt automatisch & durch &." und alles ist gut \o/
¤: Dieses Board machts genau falsch ... 
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von Meister Zopf am 31.03.2008 8:13]
|
|
|
|
|
|
|
|
|
|
Dann guck ich mir das nochmal an, vielleicht habe ich auch einfach zuweit gedacht...
|
|
|
|
|
|
|
|
|
|
|
Ich schreib unvollständige Sachen auch gerne in die Datenbank und sag dann nachher nochmal dass Fehler aufgetreten sind (z.B. leere Felder) und frag dann nur noch diese Felder ab.
Klappt ganz gut. Man braucht dann natürlich auch eine Routine die leere/unvollständige Elemente nicht anzeigt oder nach einiger Zeit löscht!
Alternativ kannst du auch Cookies anlegen bis der Arzt kommt!
|
|
|
|
|
|
|
|
|
|
|
In die Datenbank schreiben, ohne das die Daten valide sind, ist aber ziemlich zickig.
Was wenn ich das Formular einschicken, zum einen mit einer falschen Angabe die aber valide ist, sowie mit einem unvaliden Feld?
Dann schreibt dien Script meine falsche Angabe schonmal in die DB und schickt mich dann zurück. Was passiert denn jetzt, wenn ich meinen Fehler korrigiere und das verbliebene Feld valide mache?
Da bleibt ja dann nur, mittels UPDATE mehr oder weniger Blind den kompletten Datensatz neu zu überschreiben. Find ich jetzt nicht so sexy.
Unter Perl bin ich mittlerweile großer Verfechter von HTML::FormFu. Das nimmt einem solche Probleme ab. Das kümmert sich ums fachgerechte auskommentieren, ich kann Abhängigkeiten und Validierungsregelungen für die Formularfelder definieren (auch komplexe Abhängigkeiten wie "Wenn A ausgefüllt muss auch B und C ausgefüllt sein"), ich kann Filter angeben, die nach erfolgreicher Validierung z.B. alle führende und abschließende Whitespaces oder HTML aus einem Formularfeld filtern und das was es wirklich sexy macjt, ist die Möglichkeit Objekte auf Basis der Daten zu erstellen. So bekomme ich von einem Datums-Feld auf Wunsch direkt ein DateTime Objekt wieder und kann dann ganz bequem damit weiterarbeiten (gleichzeitig kann ich auf wunsch trotzdem noch auf die vom User übermittelten Rohdaten zugreifen).
Solche Frameworks sind absolut nicht zu unterschätzen, machen einem das Leben leichter und die Anwendung gleichzeitig sicherer und für den Nutzer am anderen Ende auch zugänglicher!
|
|
|
|
|
|
|
|
| Thema: escapen - unescapen - escapen ( PHP-Panschen für Anfänger ) |
