tinyMCE, CK-Editor - Client-Server-Verhalten

[Rolf B]

Hallo Tom,

außer dem, was Du uns im Hamburg erzählt hast, ist dieses Posting hier die erste klare Aussage, wo Du eigentlich hinwillst. In einem Thread, der mit "tinyMCE" übertitelt ist (was später durch Client-Server Verhalten ergänzt wurde), wäre diese Aufstellung zum Einstieg recht nützlich gewesen.

Ich würde annehmen, dass man ein System, so wie es Dir vorschwebt, auf viele unterschiedliche Arten realisieren kann und es kein Patentrezept dafür gibt.

Benutzerprofil: Du möchtest festlegen, was ein bestimmter User im Editor eingeben darf. Sinnvollerweise legt man dafür genau das fest: Einige Rechteprofile (d.h. eine benannte Auflistung von Erlaubnissen), von denen einem konkreten Benutzer eines zugewiesen wird. Das Rechteprofil des Benutzers muss dann an den Client übermittelt werden, z.B. als JSON-String.

Frontend-Gestaltung: Ja. Das gestaltet man. Nach drölftausendundeins verschiedenen Methoden, würde ich sagen. Ob TinyMCE oder CKEditor da irgendwas vorgeben, weiß ich nicht, deswegen halte ich mich da raus.

Post-Varianten (legitime und illegitime): Hängt sicherlich auch davon ab, was die Editoren ausspucken. Liefern sie ein HTML Fragment als String? Dann schick's halt hoch. Die Validierung sollte ja über die Editor-Konfiguration erfolgt sein, so dass Normalbenutzer keine serverseitige Fehlermeldung mehr bekommen sollten. Betrüger bekommen ihren POST um die Ohren gehauen. Und falls es eine Diskrepanz zwischen Client-Erlaubnissen und Server-Erlaubnissen gibt (was Du vermeiden willst, was aber ggf. vorkommen kann), bekommt der Normaluser ebenfalls eine Servermeldung. Der Server hat das letzte Wort bei "erlaubt" vs "nicht erlaubt". Das ist jetzt aber nichts, was für deinen Usecase spezifisch ist, das macht man immer so.

Postauswertung: Ja. HTML Parser. Tyrannosuchus Regex ist hier überfordert. Problem bei PHP ist, dass DOMDocument nicht HTML5 geeignet ist; es spuckt Errors aus die es nicht geben sollte, weil es auch in PHP8 noch eine libxml-Version benutzt, die kein HTML 5 kennt (z.B. regt er sich über <main> auf). Die Alternativen, die ich bisher gefunden habe, schienen auch nicht gut gepflegt zu sein, aber das ist schon eine Weile her und ich bin auch der Typ, der bei Komponenten, die mir für den Include einer Datei Composer, NPM, Grunt oder sonstiges Geraffel aufdrängen wollen, sich gleich wieder umdreht. Leider sind das mittlerweile die meisten. Bisher hatte ich keinen Bedarf für einen Parser, deshalb konnte ich mir diese Haltung leisten und ich kann Dir keine Alternative zu DOMDocument empfehlen.

Korrekturen: Siehe Frontend-Gestaltung. Drölftausendundeins Möglichkeiten, wie man das designen kann. Im einfachsten Fall rotzt man eine Liste der verbotenen Dinge raus, die der böse User benutzt hat, und lässt ihn damit allein. Da ein korrekt konfigurierter HTML Editor am Client kein verbotenes HTML liefern können sollte, reicht es vermutlich sogar, wenn man den POST mit HTTP 400 Bad Request und einem leeren Eingabefeld beantwortet.

Datenbankrechte: Gibt es. Hat aber eigentlich mit dem Bearbeitungszyklus eines HTML WYSIWYG Editors nichts zu tun. Das eingegebene und validierte HTML wird zum DB-Kontext passend maskiert (oder ein Statement dafür präpariert) und über eine UTF-8 Connection in eine UTF-8 fähige DB geschrieben.

Abweisung, bzw. Annahme des Posts: Siehe oben.

Was Dir in deiner Liste fehlt, ist:

Darstellung des Ergebnisses: Ein vom User eingegebenes HTML Snippet sollte kein Selbstzweck sein, sondern irgendwo Anwendung finden. Dabei gibt es zwei Möglichkeiten: Das Snippet steht für sich, oder das Snippet bildet ein Template für Datenausgaben. Wenn es für sich steht, kannst Du es bei der Ausgabe 1:1 in den Output-Stream schreiben. Eine Maskierung darf nicht stattfinden, sonst wird das HTML im Browser nicht wirksam. Und eine weitere Prüfung auf erlaubte Tags ist überflüssig, denn deiner eigenen DB solltest Du vertrauen können. Alles, was Du dazu beim Ausgeben prüfen könntest, kannst und solltest Du vor dem Speichern prüfen. Eine Prüfung bei der Ausgabe ist nur in einem Fall erforderlich: Wenn sich Rechteprofile verändern können und Du möchtest, dass ein HTML Snippet den bei der Ausgabe geltenden Rechten des Autors entsprechen muss. Das macht man aber eigentlich nicht - wenn jemand das Recht hat, bestimmte Dinge zu erstellen, dann sollte das Aberkennen dieses Rechts nicht dazu führen, dass diese Dinge zerbröseln. Beispielsweise könnte User X über 5 Jahre HTML Snippets erzeugen und wechselt dann die Stelle, was dazu führt, dass er das Recht dazu ganz oder teilweise verliert. Die vorhandenen Snippets werden deswegen aber nicht ungültig. Anders ist es, wenn ein User mit hohen Rechten diese Rechte missbraucht und bösartige Snippets erzeugt. Das ist aber der Ausnahmefall, dafür sollte auch eine Ausnahmebehandlung erfolgen (manuelles Sichten und Löschen, oder Rechtereduktion und ein Prüfbatch, der die Snippets auflistet oder löscht, die den neuen Rechten nicht entsprechen). Das gehört definitiv nicht in den Mainstream der Verarbeitung.

Für den Fall, dass das Snippet ein Template bildet, musst Du natürlich zum einen prüfen, ob die Templatemarker korrekt sind (vor dem Speichern) und sie vor der Ausgabe durch Inhalte ersetzen - DIESE müssen natürlich kontextgerecht maskiert werden.

WIE man das darstellt, ist eine andere Frage. Viel Prosa, würde ich annehmen. Und beachte bitte, dass jedes dieser Teilprobleme viele gültige Lösungen haben kann, von denen der Anwender die für seinen Kontext beste wählen muss.

Rolf