HTML in Formularen (Zeilenumbrüche)

[Rayse]

N'abend Jungs.

Ich arbeite derzeit an einer kleinen Webanwendung die unter anderem ein PN System beinhaltet.

Das erste Problem was sich mir stelle waren die Zeilenumbrüche, welches aber relativ schnell mittels ln2br() behoben werden konnte.

Allerdings sind die <br /> Tags ja Teile von HTML. Da es ja immer empfehlsam ist Formulare zu prüfen und ggf. zu filtern, wird dies hier ebenfalls getan u.a. mit htmlspecialchars().

Allerdings kommen sich die beiden Funktionen nun in die Quere. ln2br() würde den Text so speichern das er hinterher so mit Zeilenumbrüchen aus der DB rauskommt wie er reingekommen ist, htmlspecialchars() verhindert das irgendwas HTML artiges in die DB reinkommt was die Zeilenumbrüche ebenfalls umfasst.

Ich denke mal aus Sicherheitsgründen wäre es ziemlich fahrlässig komplettes HTML in einem solchen Formular zu erlauben, vielleicht hat ja jemand einen Tipp wie ich das Zeilenumbruch Problem elegant löse ohne gleich sämtliches HTML aktivieren zu müssen.

Gruß

Rayse

 

[crash]

Also HTML richtet in einer Datenbank keine Schäden an. Du kannst es auch vorher mittels strip_tags() entfernen.

Bei der Ausgabe machst du dann nl2br(htmlspecialschars($test));

 

[vitus37]

HTML-Sonderzeichen sollten nur deswegen maskiert werden, damit z.B. kein Schadcode wie JavaScript in deine Seite eingebunden werden kann. Die Maskierung sollte, wie crash schon sagte, bei der Ausgabe erfolgen.

 

[Rayse]

Das leuchtet ein. Auf die Idee bin ich noch gar nicht gekommen das ganze erst bei der Ausgabe zu "entschärfen", aber ist natürlich völlig logisch. Vielen Dank, dann weiß ich wie ich das lösen kann.

 

[Mogria]

Es kommt auch noch viel vor, dass man seine Ausgabe entschärft in der Datenbank speichert, um performanter zu sein.

 

[mermshaus]

Das wäre eigentliche Sache von Caching. Es kann das Generieren von Inhalt sehr unflexibel oder gar fehlerhaft machen, wenn die Originaldaten zu sehr für ein bestimmtes Ausgabeszenario (HTML, PDF, ...) optimiert in der Datenbank gespeichert werden. Nicht immer ist ein verlustfreies Konvertieren möglich.

Die gecachten/optimierten Daten können natürlich prinzipiell wiederum in der Datenbank abgelegt werden. Nur ist es häufig nicht ratsam, die Originaldaten zu verwerfen.