Editor-Wechsel WCF 2.2+

  • Nein. Firefox macht andere Probleme andere Chrome. WYSIWYG-Editoren sind eine Wissenschaft für sich, da ist kein Browser ausgenommen. Siehe auch Beitrag von Marcel, erster Absatz…

    • Offizieller Beitrag

    Vorhin ist es mir sogar mehrfach gelungen, beim Entfernen einer Zeile über einem Zitat den kompletten Firefox-Browser zum Absturz zu bringen (hier einer meiner Absturzberichte: https://crash-stats.mozilla.com/report/index/f…a0-a4b7f2160403).

    Wenn ich den Stacktrace korrekt verstehe (und das ist in dem Falle eher Marke "educated guess"), dann kam es bei der konkreten DOM-Operation zum Löschen von Nodes auf Basis der Auswahl zum Absturz. Wenn ich mir dazu die relevanten Stellen im Code anschaue, spricht das eher für eine "NullPointerException" und damit für eine Ursache innerhalb des Browsers. Das ist aber - wie bereits angemerkt - nur eine Vermutung meinerseits.

  • Ich will das gar nicht ausschließen, dass die Ursache im Browser zu suchen ist, zumal ich bewusst eine Nightly-Version von Firefox einsetze, um Fehler im Browser frühzeitig zu erkennen und zu melden. Und selbst wenn es nicht der Browser ist, wäre der Fehler wahrscheinlich eher seitens Redactor zu beheben als seitens WCF/WBB.

    Um das Problem genauer zu untersuchen (andere Browserversionen, Schritte zum Reproduzieren etc.) habe ich momentan leider überhaupt keine Zeit, darum gab es auch keine Fehlermeldung im Fehlerforum von mir. Ich habe es hier nur genannt, weil es zum allgemeinen Frust über die Probleme dazu kam. ;)

  • Die Möglichkeit, die Buttons auch im Quellcode-Modus zu verwenden

    das sollte es wirklich geben. ich frag mich warum das hier nicht geht.
    ich bin mir nich sicher aber ich glaube im 3/3.1er wbb ging es auch oder nicht?
    oder man könnte anstelle WYSIWYG zu editieren, dass man eben zusätzlich zum Code ne realtime Vorschau bekommt (nebenan, untendrunter, als tab, is mir egal). dann hat man ggf auch weniger das Problem von vielen WYSIWYG lösungen, egal ob BBCode-editoren, HTML-Programmen oder bspw SVG-Programmen.

    Komplett verwursteter Müll als Code, da manchmal sowas drölfzigtausendmal hin und her negiert wird oder whatever.

    da ich jetzt nicht auf Komplexe Formatierungen setze (zu faul) passiert mir das selten aber sowas ist mir allgemein gesagt schon ofter passiert.

    aus angst vor Capslock nutze ich selten shift.

    in fear of capslock I rarely use shift.

  • Mich würde ja mal interessieren ob nicht auch generell der Support von BB Code ein Problem bei den WYSIWYG Editoren in Foren darstellt. Immerhin läuft das ganze ja dann über 2 Stufen. BB Code muss in HTML umgewandelt werden und das HTML wird im Editor dann dargestellt. Ich kann mir vorstellen, dass bei der Umwandelung von BB Code in HTML und zurück sehr viele Fehler passieren können. IPB hat ja den Support von BB Code ganz eingestellt wenn ich richtig informiert bin. Ich finde das eigentlich keine schlechte Sache, zumindest wenn der WYSIWYG Modus ordentlich funktioniert.

    98% aller PC Probleme sitzen direkt davor.

  • IPB hat ja den Support von BB Code ganz eingestellt

    was mir teils aufn Zeiger geht wenn der spaß-editor (die abkürzung nervt langsam, wenn man die jedesmal eingeben muss) mal wieder mist baut, und dass kann schneller gehen als man denkt.

    Umwandelung von BB Code in HTML und zurück

    wieso zurück. unter der Haube passiert alles in BB (in der Theorie). der user kriegt HTML zu sehen (via javascript nehme ich an). da is nix mit zurück von HTML zu BBCode, selbst in der Datenbank steht iirc BBCode.

    aus angst vor Capslock nutze ich selten shift.

    in fear of capslock I rarely use shift.

  • das geht so aber nicht, tatsächlich muss intern immer ne umwandlung vom HTML in bbcode stattfinden.
    So funktioniert das im Browser nun mal, es gibt dort den sogenanngten design modus (den alle editoren nutzen) der es erlaubt direkt im HTML zu schreiben. Am ende hat man also plain HTML welcher vor dem speichern dann zunächst in bbcode zurück gewandelt werden muss.

    • Offizieller Beitrag

    @Garma Die Umwandlung von BBCode <-> HTML im Editor ist in der Tat problematisch und für die meisten Fehler im Zusammenhang mit dem Editor verantwortlich. BBCodes bilden nur eine sehr kleine Teilmenge von HTML ab und können den Umstand nicht berücksichtigen, dass es in HTML viele Möglichkeiten gibt einen Zustand (z.B. eine Formatierung) abzubilden. Faktisch hat jeder Browser seine eigene Auffassung wie eine Formatierung im Design-Modus (darauf basieren alle WYSIWYG-Editoren) "unter der Haube" umgesetzt wird und kann mitunter auch unterschiedlich auf dasselbe HTML reagieren.

    BBCodes als solche sind ein Relikt aus den frühen Tagen der Foren und dank der heute verfügbaren Technologien (u.a. der zuvor genannte Design-Modus) auch nicht mehr wirklich notwendig. Der einzige Sinn bestand darin dem Nutzer eine einfache Möglichkeit zur Formatierung von Texten zu geben. Ein [url]http://example.com[/url] ist einfacher einzugeben als <a href="http://example.com">http://example.com</a> und auch einen Zeilenumbruch mit <br> zu kennzeichnen ist für Laien alles andere als intuitiv.

    Ein WYSIWYG-Editor umgeht dieses Problem in dem es dem Nutzer eine Formatierung à la Word ermöglicht und es schlussendlich für den Benutzer irrelevant macht wie es technisch am Ende umgesetzt wird. Ein weiterer Aspekt ist die Nutzung auf mobilen Touch-basierten Geräten, die eckigen Klammern befinden sich i.d.R. erst auf einer zusätzlichen Tastatur. Ich habe es mir daher abgewöhnt auf meinem Smartphone die BBCodes manuell einzugeben, eben weil es eine halbe Ewigkeit dauert.

    Aus meiner Sicht wäre der ideale Mittelweg eine reine Nutzung von HTML, mit der optionalen Eingabe von BBCodes die Server-seitig beim Speichern in HTML umgewandelt werden. Auf diese Weise würde man konsistent mit HTML arbeiten, erlaubt es den "alten Hasen" aber auch weiterhin die Nutzung von BBCodes zur schnelleren Eingabe; Eine Funktion die ich z.B. beim tt-BBCode selbst oft genug nutze.

  • Formatierung im Design-Modus

    gut das wusste ich ne dass es sowas gibt, ich hätte jetzt gedacht dass hier js die arbeit übernimmt.

    Aus meiner Sicht wäre der ideale Mittelweg eine reine Nutzung von HTML, mit der optionalen Eingabe von BBCodes die Server-seitig beim Speichern in HTML umgewandelt werden

    da wäre ich vorsichtig. erstmal müsste man das HTML dann gut filtern. und bei syntaktisch falschem HTML endet das GGF nicht sonderlich gut.

    und wenn irgendwie in der tabelle was weiß ich wie man da jetzt reinkommt gibt sicher genug wege auch notfalls abseits von WCF) dann gibt es das problem dass man dann zeug ohne probleme injecten könnte.

    aus angst vor Capslock nutze ich selten shift.

    in fear of capslock I rarely use shift.

  • Woher nimmst Du das Selbstbewusstsein, nachdem Du gerade von Alex über einen Irrtum Deinerseits aufgeklärt wurdest, ihm prompt im nächsten Absatz erklären zu wollen, worauf man bei seiner angedachten Art der Umsetzung achten müsste?


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

  • das war nicht spezifisch an ihn, sondern allgemein, es ist ja nicht nur er, der das hier liest.

    und so wie es MySQL injection gibt würde es bei einem Internen Full HTML eine HTML injection geben, das Problem ist nur dass eine HTML injection nicht so schnell verhindert werden kann wie eine MySQL incjetion jetzt mit PDO verhindert wird, da müsste man das HTML schon checken.

    und man kann ja nicht alles wissen.

    aus angst vor Capslock nutze ich selten shift.

    in fear of capslock I rarely use shift.

  • Sorry, aber bevor ich derartige Aussagen für bare Münze nehme, möchte ich das schon von jemandem bestätigt haben, in dessen Kenntnisse ich Vertrauen habe.


    Gruß norse

    Zugang zu meinen Arbeiten und dem dazugehörigen Support bekommt Ihr bei Interesse hier und hier.

  • also allein mit einem

    HTML
    </div>
    </div>
    </div>
    </div>
    </div>
    </div>

    kann man ohne Filter schonmal ordentlich was verunstalten.

    einfach mal auf HTML modus umschalten aus probieren. bzw, schon passiert.

    hau dann noch n js rein (dass ggf noch böses macht) und viel spaß.

    es gibt einen grund warum normale user kein HTML dürfen.

    @SoftCreatR das könnte helfen. müsste man mal testen. Wobei ich sagte man, man braucht dann nen filter, was das ja im prinzip ist.

  • Die Frage ist eher ob man Tools wie den HTML Purifier überhaupt braucht. Ich weiß nicht wie die gängigen Editoren intern funktionieren, aber sollte es nicht möglich sein, das tatsächlich Geschriebene und das durch den Editor hinzugefügte HTML zu unterscheiden? Falls ja kann man ja schon bei der Texteingabe das HTML herausfiltern.

    98% aller PC Probleme sitzen direkt davor.

  • ist doch völlig egal, ich kann als böswilliger user dennoch an den server senden was ich möchte, jede filterung muss also serverseitig geschehen.
    Der Link den @SoftCreatR gepostet hat ist btw bestandteil des wcf2.2 da hier das CMS genau auf plain HTML basiert ;)

    • Offizieller Beitrag

    und so wie es MySQL injection gibt würde es bei einem Internen Full HTML eine HTML injection geben, das Problem ist nur dass eine HTML injection nicht so schnell verhindert werden kann wie eine MySQL incjetion jetzt mit PDO verhindert wird, da müsste man das HTML schon checken.

    Bei BBCodes gibt es im übrigen das gleiche Problem, dort muss man auch sehr sorgfältig prüfen.

    Letztlich bleibt die Grundregel: "User input is evil", was sinngemäß bedeutet, dass Nutzereingaben grundsätzlich als schadhaft sein können - unabhängig ob dies wissentlich geschieht oder nicht. Dein Beispiel bzgl. mehreren </div> ist etwas unglücklich, denn die HTML-Eingabe wird in WCF 2.1 (und den Vorgängerversionen) ungeprüft übernommen, nicht umsonst ist dies standardmäßig für Nicht-Administratoren deaktiviert.

    HTMLPurifier hingegen ist gegenwärtig das Maß aller Dinge wenn es um die Filterung von HTML geht, denn es basiert auf einer klar definierten Whitelist inklusive der Sicherstellung der in sich geschlossenen Gültigkeit der Eingabe. Dieses Vorgehen erlaubt es exakt festzulegen welche Inhalte akzeptiert werden, womit das selbe Maß an Sicherheit gewährleistet werden kann im Vergleich zu BBCodes.

  • ich sagte ja man muss gut filtern/prüfen.
    gut die runde mit dem div sprengen ist eben genau ein beispiel von dem was passier wenn alles ungefiltert kommt.

    Letztlich bleibt die Grundregel: "User input is evil",

    genau darauf wollte ich hinaus. man sollte aber auch mMn auf den Output achten dass nichtmal plötzlich hintenrum irgendwas passiert, also böses HTML in der DB.


    Dein Beispiel bzgl. mehreren </div> ist etwas unglücklich, denn die HTML-Eingabe wird in WCF 2.1 (und den Vorgängerversionen) ungeprüft übernommen

    genau das muss geändert werden bevor auf HTML gewechselt wird.

    was auch ne interessante frage wäre performance zwischen BBCode und HTML Purifier zu testen, nicht das plötzlich alles sehr langsam wird.

    aber sollte es nicht möglich sein, das tatsächlich Geschriebene und das durch den Editor hinzugefügte HTML zu unterscheiden?

    nicht unbedingt. man kann javascript ohne probleme durch nen debugger ziehen, also unterbrechen, manipulieren etc, was bei PHP nicht geht wenn man nicht der Server ist, und somit gut gefaketes zeug vortäuschen...

    aus angst vor Capslock nutze ich selten shift.

    in fear of capslock I rarely use shift.

  • Bitte, bitte, bitte - 1 Standard.

    Also wenn im CMS mit HTML-Purifier, dann bitte plattformübergreifend in allen EA und bitte keine Einzellösungen.

    Danke & Grüße, CCFF

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!