tinyMCE

[TS]

Hello,

trifft es zu, dass man tinyMCE nicht mehr vom eigenen Server aus laden kann (rechtlich)? Man muss sich einen Product-Key für die Domain holen, auf der man es benutzen will und die JS-Dateien von

<script src="https://cdn.tiny.cloud/1/2cbgmudc3z1======≈xh762e04/tinymce/5/tinymce.min.js" referrerpolicy="origin"></script>

(Key unbrauchbar gemacht)

herunterladen?
Was sagt die Same Origin Policy dazu?

Oder kann ich die JS-Module immer noch wie früher auf meinem eigenen Server hosten?

Glück Auf
Tom vom Berg

[Rolf B]

Hallo TS,

so wie ich das hier lese, ist cloud install eine von mehreren Optionen und nicht verpflichtend.

Ob die Varianten bestimmte Vor- und Nachteile haben, oder funktionelle Beschränkungen, habe ich jetzt nicht studiert.

Und weshalb die Cloud-Variante unbedingt einen API Key braucht verstehe ich auch nicht.

Rolf

[Auge]

Hallo

Und weshalb die Cloud-Variante unbedingt einen API Key braucht verstehe ich auch nicht.

Ist das denn überhaupt der Fall?

Der Beispielcode der Installationsanleitung für die Nutzung über die Cloud – bei abgeschaltetem JS clevererweise in schwarzer Schrift auf dunkelstgrauem Grund – enthält als Pfadbestandteil die Angabe no-api-key, die Notwendigkeit eines API-Keys wird hingegen nicht erwähnt. Auch die weiteren Code-Beispiele, die ich in dem Abschnitt Installation per Cloud und auf der zum Abschluss verlinkten Seite zur Arbeit mit Plugins gefunden habe, benutzen die Angabe no-api-key im Pfad zum laden des Skripts über die Cloud.

<script src="https://cdn.tiny.cloud/1/no-api-key/tinymce/5/tinymce.min.js" referrerpolicy="origin"></script>

Es wäre also interessant, woher @TS die Info hat, dass man einen API-Key haben müsste. Das muss ja irgendwo anders geschrieben stehen.

Tschö, Auge

[TS]

Hello,

<script src="https://cdn.tiny.cloud/1/no-api-key/tinymce/5/tinymce.min.js" referrerpolicy="origin"></script>

Es wäre also interessant, woher @TS die Info hat, dass man einen API-Key haben müsste. Das muss ja irgendwo anders geschrieben stehen.

Tja, ich habe wohl ein Händchen für die Fettnäpfchen oder von der falschen Seite anzufangen. Ich wollte eigentlich nur regelmäßig über Weiterentwicklungen informiert werden. Da haben sie mir den Key angedreht ;-)

Sign up for free

Glück Auf
Tom vom Berg

[Rolf B]

Hallo Tom,

das Problem ist - wie so oft - dass die Doku von Leuten geschrieben wurde, die die Tiny-Welt kennen, denen alle Begriffe vertraut sind und die komplett damit überfordert sind, ihre Welt jemandem zu erklären, der gerade einsteigt.

Ich als TinyMCE-Unkundiger stehe vor der Seite, finde eine Menge Optionen und niemand sagt mir, nach welchen Kriterien ich mich für eine davon entscheiden sollte. Ich muss hin- und herlesen und glaube zu erraten, dass die Premium Plugins nur mit einem API Key verfügbar sind. Und dass es wohl die einfachste Lösung sei, mit der Tiny Cloud zu arbeiten.

Und dann lese ich, dass es wohl auch ohne Cloud geht. Auch mit Premium. Wie auch immer das sicher funktionieren soll - denn Tiny muss ja verhindern, dass jemand meinen API Key aus meiner Site herauskopiert und mit meinem Key Premium-Features nutzt.

Einsteigerkompatible Doku zu schreiben ist eine sehr schwierige Kunst. Das merke ich auch immer, wenn ich was für's Wiki schreiben will.

Rolf

[Mitleser 2.0]

Tja, ich habe wohl ein Händchen für die Fettnäpfchen oder von der falschen Seite anzufangen.

Scheint so ;-)

Self-Hosted Install so versteckt anzubieten, hat IMHO aber schon ein Geschmäckle :-(

[TS]

Hello,

Self-Hosted Install so versteckt anzubieten, hat IMHO aber schon ein Geschmäckle :-(

oder besser gleich hier: Download-Seiten

Scheint also noch möglich zu sein.

Jetzt muss ich nur die dazugehörigen Lizenzbestimmungen finden und verstehen...

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber TS,

der TinyMCE ist freie Software: TinyMCE auf Github

Wenn Du nicht selbst hosten willst, dann bietet Dir die Firma diverse Konditionen an, für die Du dann den API-Key benötigst.

Liebe Grüße

Felix Riesterer

[TS]

Hello lieber Felix,

der TinyMCE ist freie Software: TinyMCE auf Github

Wenn Du nicht selbst hosten willst, dann bietet Dir die Firma diverse Konditionen an, für die Du dann den API-Key benötigst.

Jau, danke. So langsam klärt sich ja alles wieder Dank Eurer Unterstützung.
Ich habe eine alte Anwendung mit einer frühen Version von TinyMCE. Die läuft nicht mehr. Da hat sich im JavaScript und im DOM mächtig etwas geändert seit damals.

Es lohnt sich also vermutlich, die mit einer neuen Version in der HTML5-Umgebung nochmal zu testen.

Glück Auf
Tom vom Berg

[TS]

Hello,

noch ein Nachtrag:

Die beiden Frontend-Editoren TinyMCE und CK-Editor werden ja nun in diversen CMS eingesetzt. Weiß da jemand mehr über die serverseitige Abriegelung bzw. Anbindung der Systeme?

Dazu gehören:

• Benutzerrechte im Editor
• Benutzerrechte auf dem Server
• Plausibilitätsprüfungen, etc.

denn immerhin ist der POST-Kanal ja ziemlich offen, also angreifbar.

Ich würde das gerne zusammen mit "Wissenden" genauer Untersuchen und dokumentieren.

Wer kann helfen?

Glück Auf
Tom vom Berg

[Der Martin]

Hallo Tom,

Die beiden Frontend-Editoren TinyMCE und CK-Editor werden ja nun in diversen CMS eingesetzt. Weiß da jemand mehr über die serverseitige Abriegelung bzw. Anbindung der Systeme?

ich kenne beide nur vom Hörensagen, habe sie nie verwendet oder mich um Details gekümmert. Insider-Informationen, auf die du vielleicht spekulierst, kann ich also nicht liefern.

Aber: Beide sind meines Wissens in Javascript realisiert. Damit beantworten sich zwei deiner Fragen schon quasi von selbst:

• Benutzerrechte im Editor
• Benutzerrechte auf dem Server

Javascript läuft im Browser in einer strikt abgeriegelten Umgebung. Benutzerrechte im eigentlichen Sinn gibt es nicht. Und zumindest zum TinyMCE gibt es meines Wissens auch keine serverseitige Komponente, der postet sein Ergebnis nachher einfach so, als sei alles nur der Inhalt eines textarea-Elements. Also ist die serverseitige Verarbeitung komplett Sache des Website-Betreibers.
CK-Editor kenne ich noch weniger, aber ich vermute, dass es da ähnlich läuft.

• Plausibilitätsprüfungen, etc.

Was stellst du dir darunter vor? Die Verarbeitung des vom Editor gesendeten Salats ist vollständig deine Sache, wenn du einen solchen Editor in einer Website einsetzt.

denn immerhin ist der POST-Kanal ja ziemlich offen, also angreifbar.

Nein. Er ist nur in dem Maß angreifbar, wie das verarbeitende Script (PHP, Perl, Python o.ä.) angreifbar ist. Der Übertragungsweg (HTTP GET oder POST) hat damit zunächst nichts zu tun.

Ich würde das gerne zusammen mit "Wissenden" genauer Untersuchen und dokumentieren.

Dann bin ich gespannt, wer sich dazu noch äußert und in welchem Umfang meine Behauptungen bestätigt oder für falsch erklärt werden.

Live long and pros healthy,
 Martin

[TS]

Hello Martin,

Die beiden Frontend-Editoren TinyMCE und CK-Editor werden ja nun in diversen CMS eingesetzt. Weiß da jemand mehr über die serverseitige Abriegelung bzw. Anbindung der Systeme?

ich kenne beide nur vom Hörensagen, habe sie nie verwendet oder mich um Details gekümmert. Insider-Informationen, auf die du vielleicht spekulierst, kann ich also nicht liefern.

Aber: Beide sind meines Wissens in Javascript realisiert. Damit beantworten sich zwei deiner Fragen schon quasi von selbst:

• Benutzerrechte im Editor

Das hast Du falsch verstanden. Das Angebot im Editor (Frontend) soll entsprechend der Nutzerrechte gestaltet werden, die Editoren also jeweils passend zu den Userrechten konfiguriert werden. Wie weit reicht da die Skalierbarkeit?

• Benutzerrechte auf dem Server

Da muss selbstverständlich nachkontrolliert werden, was der Client gesendet hat.

Das bedeutet also, dass man die Anweisungen an den Fronteditor übersetzen muss auf die Regeln des Servers (DOM-Parser, Filerechte, Filter, etc.)

Glück Auf
Tom vom Berg

[Mitleser 2.0]

Das hast Du falsch verstanden. Das Angebot im Editor (Frontend) soll entsprechend der Nutzerrechte gestaltet werden, die Editoren als passend konfiguriert werden. Wie weit reicht da die Skalierbarkeit?

Du willst den TinyMCE also individualisieren? Da geht eigentlich alles - bis hin zu einer "Eingabe only" und dann kannst Dir Deine gewünschte GUI drumherumbauen.

Was das aber mit

denn immerhin ist der POST-Kanal ja ziemlich offen, also angreifbar.

zu tun haben soll, ist mir auch komplett schleierhaft.

Es ist wie Der Martin schon schrieb: Du bekommst auf dem Server letztlich einen dicken (gerne auch gruseligen) HTML-Blupp vor den Latz geknallt. Wenn Du den „prüfen“ und gegen Nutzerrechte abgleichen willst, dann musst den Markup-Blupp parsen und entsprechend behandeln / bereinigen.

Das hat mit TinMCE aber halt nix zu tun. Das Problem hättest Du analog bei einer schnöden Textarea.

[TS]

Hello,

Das hast Du falsch verstanden. Das Angebot im Editor (Frontend) soll entsprechend der Nutzerrechte gestaltet werden, die Editoren als passend konfiguriert werden. Wie weit reicht da die Skalierbarkeit?

Du willst den TinyMCE also individualisieren? Da geht eigentlich alles - bis hin zu einer "Eingabe only" und dann kannst Dir Deine gewünschte GUI drumherumbauen.

Genau so ist es. Der User soll nur Möglichkeiten im Frontend angeboten bekommen, für die er freigeschaltet ist. Darf jemand*in keine Bilder hochladen, bekommt er*in eben die Option gar nicht erst angeboten.

Was das aber mit

denn immerhin ist der POST-Kanal ja ziemlich offen, also angreifbar.

zu tun haben soll, ist mir auch komplett schleierhaft.

Die Ergebnisse der Frontend-Aktion werden am Ende gepostet (POST). Die können aber auch gefaked werden, also muss das verarbeitende Script erst wieder prüfen, ob nur erlaubte Elemente und Parameter gesendet wurden.

Es ist wie Der Martin schon schrieb: Du bekommst auf dem Server letztlich einen dicken (gerne auch gruseligen) HTML-Blupp vor den Latz geknallt. Wenn Du den „prüfen“ und gegen Nutzerrechte abgleichen willst, dann musst den Markup-Blupp parsen und entsprechend behandeln / bereinigen.

Ja, genau. Ich habe nichts anderes behauptet.

Es gebt also um das Gesamtsystem.

Glück Auf
Tom vom Berg

Edit Rolf B: Toms Gendersternchen escaped, um Kursivsatz zu vermeiden.

[Mitleser 2.0]

Die Ergebnisse der Frontend-Aktion werden am Ende gepostet (POST).

Ach was!

Die können aber auch gefaked werden, also muss das verarbeitende Script erst wieder prüfen, ob nur erlaubte Elemente und Parameter gesendet wurden.

Nochmal: was zum Henker hat das mit TinyMCE zu tun?!

[TS]

Hello,

Die Ergebnisse der Frontend-Aktion werden am Ende gepostet (POST).

Ach was!

Die können aber auch gefaked werden, also muss das verarbeitende Script erst wieder prüfen, ob nur erlaubte Elemente und Parameter gesendet wurden.

Nochmal: was zum Henker hat das mit TinyMCE zu tun?!

Was verstehst DU denn daran nicht? Formuliere das doch mal verständlich und bölke hier nicht nur herum!

Glück Auf
Tom vom Berg

[Mitleser 2.0]

Was verstehst DU denn daran nicht? Formuliere das doch mal verständlich

Hab ich bereits, aber gerne nochmal: wo liegt der Unterschied, ob Dir der TinyMCE, der CK-Editor oder z.B. eine einfache Textarea Dein HTML-Blupp an den Server schickt?

und bölke hier nicht nur herum!

Die IMHO einzig stimmige Frage, die von Dir hier in diesem Subfred letztlich gestellt (nachdem Du Martin zunächst „Das hast Du falsch verstanden“ vor den Latz geknallt hast) wurde, war die nach der Frage der Individualisierbarkeit TinyMCE. Die hat der „Rumbölker“ (Protipp: Ich) Dir mit einem „Geht alles“ beantwortet.

Mit etwas Fantasie hätte ich mir sogar einen konkreten Kontext bzgl. der serverseitigen Verarbeitung/Validierung/Korrektur von solchen HTML-Monstern (egal wie clientseitig generiert) vorstellen können: die Frage, wie und womit man sowas am besten anstellt.

Aber nein, wieder dieses seltsame Rumgeschwurbele von Dir. Ich scheine nicht alleine mit meiner Ratlosigkeit, was Du eigentlich willst.

[TS]

Hello,

Aber nein, wieder dieses seltsame Rumgeschwurbele von Dir. Ich scheine nicht alleine mit meiner Ratlosigkeit, was Du eigentlich willst.

Nun sei mal nicht immer nur destruktiv mit deiner Kritik.

Ich könnte mir vorstellen, dass Du mir bei der Formulierung des gesamten Roundturns nebst Konfigurationsmöglichkeiten durchaus behilflich sein könntest. Und danach sollte auch Dir klar sein, wie ich das meinte mit den "Benutzerrechten" (aka Angeboten) für den Client (also MCE oder CK).

Hier geht es um die Definition und Abbildung der Rechte, Prüfungen und Funktionen auf alle Module des gesamten Zyklus.

Also

• Benutzerprofil
• Frontend-Gestaltung
• Post-Varianten (legitime und illegitime)
• Postauswertung (HTML-Parser?)
• Korrekturen?
• Datenbankrechte
• Abweisung, bzw. Annahme des Posts
• ...

Glück Auf
Tom vom Berg

[Mitleser 2.0]

Ich könnte mir vorstellen...

Ich kann mir auch einiges vorstellen. An dieser fruchtlosen Soße weiter mitzumischen gehört nicht dazu.

Mach Du mal Dein „tinyMCE, CK-Editor - Client-Server-Verhalten“ Pamphlet. Viel Erfolg.

[TS]

Hello,

Ich könnte mir vorstellen...

Ich kann mir auch einiges vorstellen. An dieser fruchtlosen Soße weiter mitzumischen gehört nicht dazu.

Genau. Ich will für die "fruchtlose Soße" ein nachvollziehbares Rezept entwickeln.

Danke, dass Du auf deine destruktiven Kommentare verzichten wirst.

Glück Auf
Tom vom Berg

[Felix Riesterer]

Lieber TS,

Ich will für die "fruchtlose Soße" ein nachvollziehbares Rezept entwickeln.

das gibt es alles schon. Daher ist Dein Ansinnen in meinen Augen das falsche. Du solltest lieber wieder zurück zu den Basics und den Unterschied zwischen Frontend (clientseitig) und Backend (serverseitig) erarbeiten. Dann wird Dir vielleicht klar, was Du bei Deiner Frage übersehen hast und warum deshalb die Reaktionen auf Deine Postings "destruktiv" sind. Aber das schrubte ich ja schon, wenn auch indirekt...

Liebe Grüße

Felix Riesterer

[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

[Raketenwilli]

Dann bin ich gespannt, wer sich dazu noch äußert und in welchem Umfang meine Behauptungen bestätigt oder für falsch erklärt werden.

Sie sind - jedenfalls im Hinblick auf das, was ich gesehen habe - offensichtlich richtig.

[Felix Riesterer]

Lieber TS,

ich wundere mich ob Deiner Fragestellungen.

Die beiden Frontend-Editoren TinyMCE und CK-Editor werden ja nun in diversen CMS eingesetzt.

Das klingt fast so, als hättest Du vergessen, wie das mit dem Unterschied zwischen Frontend (browserseitig) und Backend (serverseitig) ist.

Weiß da jemand mehr über die serverseitige Abriegelung bzw. Anbindung der Systeme?

Welche Systeme meinst Du? TinyMCE und CK-Editor kannst Du nicht meinen, denn die haben kein Backend, sondern nur ein Frontend. Ja, man kann sie mit beliebigen Plugins ausrüsten, die ihrerseits serverseitige Komponenten haben, aber das ist eine völlig andere Baustelle und gehört zur Integration dieser Editoren in CMSe.

Dazu gehören:

• Benutzerrechte im Editor
• Benutzerrechte auf dem Server
• Plausibilitätsprüfungen, etc.

denn immerhin ist der POST-Kanal ja ziemlich offen, also angreifbar.

Was ein serverseitiges System mit POST-Daten tut, ist von TinyMCE und CK-Editor völlig unabhängig. Insofern ist Deine Fragestellung falsch!

Ich würde das gerne zusammen mit "Wissenden" genauer Untersuchen und dokumentieren.

Nenne mir ein CMS, welches einen (oder gar beide) dieser Editoren einsetzt, dann kann man über das Backend davon sprechen und über Deine aufgeführten Punkte genauer schauen.

Wer kann helfen?

So wohl gerade niemand. Aber das liegt an Deiner Fragestellung.

Liebe Grüße

Felix Riesterer