HTML in Datenbank speichern

Hallo Zusammen,

ich habe das Forum schon durchsucht, aber leider keine passende Antwort gefunden.

Ich bastel an einem kleinen CMS mit dem der User via WYSIWYG-Editor HTML Code in eine Datenbank speichert, der wiederum an anderer Stelle ausgegeben werden soll.

Wenig sinnvoll wird es ja sein, den HTML Code einfach so wie er ist in der Datenbank zu speichern.

Kann mir Jemand einen Tip geben, was ich beim speichern in die DB und beim ausgeben in den Editor sowie als HTML seite beachten sollte.

Welche Funktionen sollte ich vorschalten?


Vielen Dank

Gruiß Jan

Original geschrieben von jandayne
Wenig sinnvoll wird es ja sein, den HTML Code einfach so wie er ist in der Datenbank zu speichern.

Warum?

sinnvoll ist das schon ... ABER .. nicht ohne den code zu überprüfen.
nicht das externer js geladen wird oder man auch php-code einbauen kann

sinnvoll ist das schon ... ABER .. nicht ohne den code zu überprüfen.
nicht das externer js geladen wird oder man auch php-code einbauen kann

In einem CMS, wo der Benutzer sich erst anmelden muss und damit zur Content-Erstellung berechtigt ist, würde ich keine Überprüfung des Codes durchführen. Das ist ja gerade Sinn der Sache, dass du deine Website direkt über diese Weboberfläche pflegen kannst.
Und ohne eval und co. wird PHP-Code eh nur wieder ausgegeben!

Worauf du lediglich achten musst, ist das escapen von Sonderzeichen in der SQL-Query, zum Beispiel mit Hilfe von mysql_real_escape_string. Da du den HTML-Code direkt ausgeben willst, musst du bei der Ausgabe nichts weiter beachten.

Original geschrieben von PHP-Desaster
In einem CMS, wo der Benutzer sich erst anmelden muss und damit zur Content-Erstellung berechtigt ist, würde ich keine Überprüfung des Codes durchführen. Das ist ja gerade Sinn der Sache, dass du deine Website direkt über diese Weboberfläche pflegen kannst.
Und ohne eval und co. wird PHP-Code eh nur wieder ausgegeben!

Worauf du lediglich achten musst, ist das escapen von Sonderzeichen in der SQL-Query, zum Beispiel mit Hilfe von mysql_real_escape_string. Da du den HTML-Code direkt ausgeben willst, musst du bei der Ausgabe nichts weiter beachten.

ok .... stimmt eben extra nochmal getestet .. egal was man eingibt, man kann kein php-code ausführen lassen (sql-injection technik verwendet).

aber js sollte man evtl. nicht zulassen, oder iframes .. etc .. alles was das leben unschöner macht.

auch wäre es blöd wenn jemand mit "fiesem" html code das design zerschießt.

und man sieht ja an myspace und anderen seiten, was man alles mit js und co so machen kann

aber js sollte man evtl. nicht zulassen, oder iframes .. etc .. alles was das leben unschöner macht.

auch wäre es blöd wenn jemand mit "fiesem" html code das design zerschießt.

Wenn der Kunde Mist eingibt und damit sein Layout zerhaut, ist das definitiv nicht schön. Aber es ist genau so unschön, wenn für jede etwas größere Änderung (JS, iframe, what-ever) direkt jemand anderes ran muss. Das kann der Kunde doch auch so schön über's Backend machen und du ersparst dir auch den hoffnungslosen Versuch, alle möglichen Tags oder Attribute zu verbieten.

Hallo Zusammen,

vielen Dank für die schnellen Antworten.

Wenn ich die Funktion mysql_real_escape_string() verwende, werden ja logischerweise slashes vor die Hochkommas gesetzt. Hierfür sollte ich bei der Azusgabe dann stripslashes() verwenden, oder?

Wo mein HTML-Code jetzt so in der DB steht:

EDIT:

---

<p>Hallo! Das ist mein CVode \"hhghgh\"vhh</p>

---

speichert z.B. Joomla wie folgt:

PHP-Code:

Hallo! Das ist mein CVode "hhghgh"vhh 


Ist dies sinnvoller?

Vielen Dank
Gruß Jan

Original geschrieben von jandayne
Hallo Zusammen,

vielen Dank für die schnellen Antworten.

Wenn ich die Funktion mysql_real_escape_string() verwende, werden ja logischerweise slashes vor die Hochkommas gesetzt. Hierfür sollte ich bei der Azusgabe dann stripslashes() verwenden, oder?

Nein. Die Backslashes dienen dazu, damit die Datenbank erkennt welche Sonderzeichen zu den Daten und welche zur Syntax gehören. Die eingefügten Daten enthalten die Backslashes nicht mehr (außer die Backslashes die escaped wurden).

Wenn ich die Funktion mysql_real_escape_string() verwende, werden ja logischerweise slashes vor die Hochkommas gesetzt. Hierfür sollte ich bei der Azusgabe dann stripslashes() verwenden, oder?

Nein, diese Slashes sind nur zum Entschärfen von Metazeichen. Solltest du noch weitere Slashes drin haben, die auch bei der Ausgabe sichtbar werden, handelt es sich wahrscheinlich um magic_quotes.

Wo mein HTML-Code jetzt so in der DB steht: (...)
speichert z.B. Joomla wie folgt...)

Ist dies sinnvoller?

Bedingt ja. Das "-Zeichen ist in HTML (genauer: XML) ein Steuerzeichen, welches du zum Beispiel für Attributwerte verwendest. Genau wie auch <, > und &. Wenn du diese Zeichen außerhalb von Tags verwendest, zum Beispiel wie hier im Text, dann musst du diese Zeichen als Entitäten schreiben.

Hallo,

um diese Zeichen als Entitäten zu schreiben, verwende ich ja die Funktion htmlentities(). Hierbei werden allerdings auch die HTML-Befehle umgewandelt.

So steht für folgenden Code:

PHP-Code:

<p>Hallo! Das ist mein CVode "hhghgh"vhh!</p> 


in meiner DB:

PHP-Code:

<p>Hallo! Das ist mein CVode "hhghgh"vhh!</p> 


in der Joomla DB z.B

PHP-Code:

<p>Hallo! Das ist mein CVode &quot;hhghgh&quot;vhh</p> 


Die hier verwendeten HTML-Befehle (wie <p>) werden bei Joomla nicht umgewandelt.

Sollte ich eine andere Funktion verwenden?

Vielen ank
Gruß Jan

htmlspecialchars_decode
html_entity_decode

Vielen Dank, UzumakiNaruto, die genannten Funktionen zum decodieren, sind mir bekannt. Meine Frage ist nur, warum bei Joomla z.B. die HTML-Codes nicht umgewandelt werden. Hat dies einen bestimmten Grund?

Als Fazit entnehme ich jetzt:
Sinnvoll ist es den Code via der Funktion htmlentities() in der DB zu speichern und mit der entsprechenden Funktion bei der Ausgabe zu decodieren.

Weiteres gibt es nicht zu beachten?


Vielen Dank für die Hilfen!

GRuß jan

Ich denke, die Entitäten kommen direkt aus dem Editor, den Joomla nutzt. Afaik ist das der TinyMCE. Welchen Editor du auch immer nutzt, der scheint die Entitäten nicht umzuwandeln.

naja ... kommt darauf an was für leute dort schreiben dürfen. sind es verantwortliche für die webseite oder besucher der webseite.

bei besuchereingaben würde ich schon das eine oder andere noch rausfiltern <script></script> aufrufe z.b.

naja ... kommt darauf an was für leute dort schreiben dürfen. sind es verantwortliche für die webseite oder besucher der webseite.

In einem CMS, wo der Benutzer sich erst anmelden muss und damit zur Content-Erstellung berechtigt ist, würde ich keine Überprüfung des Codes durchführen.