Ungefiltertes HTML zulassen

  • "Ziel erreicht" sicher nicht. Aber ich finde es gut, dass man sich scheinbar endlich mit dem Thema beschäftigt. Und ganz ehrlich: Bevor am Ende gar nichts gemacht wird (wonach es bisher ja aussah), wäre ein BBCode immer noch besser. Dass das im Vergleich zum WBB4.1 aber ein deutlicher Rückschritt ist, steht außer Frage.

    Eigentlich würde ich es auch so erwarten, wie norse es z.B. im ersten Beitrag dieses Threads geschrieben hat. Ohne BBCode. Aber erwarten würde ich eh vieles. Wieder einen anständigen BBCode Modus statt diesem unübersichtlichen HTML Modus, Signaturen pro Beitrag deaktivieren, Beitragstitel, etc blabla. Mittlerweile habe ich mich allerdings damit abgefunden, dass das meiste im WBB5 nicht so kommen wird, wie ich es erwarten würde. Ist eben eine sehr eigenartige "Weiterentwicklung".

  • Doch Ziel erreicht. Ein User findet sich mit ab auch wenn widerwillig ;)

    3.1 auf 4.0 wegfall von Funktionen aber kamen in Form von Plugins wieder, 4.0 auf 4.1 wieder Einbau oder aber mit Plugins ersetzt, 4.1 auf 5.0 wegfall vieler Funktionen + ACP Unübersichtlicher als vorher + noch einiges anderes und in der Betaphase von den Entwicklern des WSC nachgereichte Funktion in Form eines BBCodes , 5.0 auf 5.1 wieder Einbau einiger Funktionen aber die meisten kommen als Plugin wieder.

    Merkst du was??

    Ich mache keine Fehler.......

    Ich erschaffe Katastrophen

  • @mcburn Das brauchst du mir nicht zu erzählen, das weiß ich selber. Ich habe ja selbst von Anfang an gesagt, dass fehlende Funktionen für mich auch dann nicht existent sind, wenn diese von Drittherstellern als Plugins kommen. Denn mir wurde auch oft genug das Argument an den Kopf geworden, dass X oder Y ja sicher als Plugin kommen wird.

    Aber hier scheint es ja offiziell von WoltLab zu kommen und dementsprechend auch mit in das WBB5 mit eingebaut zu werden. Zumindest interpretiere ich das so. Es wäre also keine fehlende Funktion, die nur als Plugin zurück kommt, sondern eher eine schlecht umgesetzte Funktion, die im WBB4.1 noch bei weitem besser war. Aber da sich nun ja scheinbar damit befasst wird, kann man mit Diskussionen und Feedback ja vielleicht noch etwas erreichen, damit es besser umgesetzt wird. Deshalb hatte ich mein Feedback dazu abgegeben.

    Ausschließlich mimimi hilft da auch nicht weiter. Oder wäre es dir lieber, wenn am Ende gar nichts gemacht wird?

    Abschließend nochmal deutlich: Nein, mit der BBCode Geschichte bin ich auch nicht glücklich. Und mit den anderen Punkten, die ich aufgelistet hatte auch nicht. Ordentlich und anständig wäre es, wenn es so funktionieren würde, wie im WBB4.1 oder sogar noch besser.

  • Ausschließlich mimimi hilft da auch nicht weiter.

    Ich habe mimi aufgegeben. Sind zu viele hier die sofort scharf schießen ;)

    Oder wäre es dir lieber, wenn am Ende gar nichts gemacht wird?

    Eventuell ja :)
    Weil WSC oder What ever ist nichts halbes und nichts ganzes. Ja es ist Beta, ja es soll Innovativ sein. Das ist ja nicht das was ich Bemängel. Es ist das was und wie Sachen gestrichen werden. Und wie NICHT drauf eingegangen wird.

    Das ist das was mich nervt. Aber es wird genug geben die es so entweder hin nehmen oder wie auch immer. Also ZIEL erreicht ;) und 5.1 bringt dann das wieder was in 5.0 fehlte.

    Ich mache keine Fehler.......

    Ich erschaffe Katastrophen

  • Naja, ich will mal ehrlich sein, eigentlich wollte ich mich mit dem Thema nicht weiter beschäftigen da ich selbst kein ungefiltertes HTML benötige.
    Aber da das ja hier von wirklich vielen gewünscht wurde hatte ich mir das aktuelle System mal etwas genauer angeschaut und mir überlegt wie man es in der aktuellen Form optimal nutzen könnte.
    Dabei herraus gekommen ist für mich folgende Überlegung die ich sogar überlegte als Plugin umzusetzen falls es irgendwann mal meine zeit erlaubt^^

    Der purifier ist im Grunde super, im Anschluss hat man wirklich sauberes HTML, ohne dass kleine Fehler (z.B. ein nicht geschlossener Tag) das Design zerstückelt.
    Die Meisten der Admins die sich hier nun beschweren benötigen im normalfall auch nicht das komplette mögliche Spektrum an HTML tags sondern meist sind es nur einige wenige Elemente die man im Alltag häufiger benötigt.
    Darum wäre der für mich richtige schritt gewesen weiterhin zu filter usw, jedoch im ACP die Möglichkeit zu schaffen eigene HTML tags (und damit einhergehend auch deren Attribute) nach belieben selbst auf die whitelist zu setzen, im ideal fall mit eigener Berechtigung.
    Damit wäre mMn allen gedient, denn derjenige der nun dringend divs benötigt mit der Möglichkeit dort inline styles einzutragen kann diese einfach im ACP einfügen, wohingegen der nächste Admin nen Iframe benötigt in dem er selbst Attribute festlegen kann usw.
    Die Einsatzmöglichkeiten wären vielfältig, und mit einigen kleineren umbauten im WSC (default klasse für unbekannte html nodes usw) wäre das ganze auch relativ einfach umzusetzen.
    Das aktuell via Plugin umzusetzen wäre aber eher nervig, da man dem Purifier zwar die whitelist problemlos beibringen kann, im redactor aber z.B. durch woltlab alle divs schon entfernt werden. Zudem ist es nicht möglich beliebige HTML tags zu generieren ohne entsprechende nodes anzulegen die diese validieren (geht nur über so unschöne verränkungen wie das element als attribut an einen meta node zu hängen und dann im output aus dem attribut wieder das original element zu rekonstruieren) :(

  • Dabei herraus gekommen ist für mich folgende Überlegung die ich sogar überlegte als Plugin umzusetzen falls es irgendwann mal meine zeit erlaubt^^

    Das wäre zumindest für mich dann keine Lösung, da ich sowas nicht als Plugin installieren würde, sondern direkt von WoltLab etwas haben möchte. Sonst kann das einfach zu unnötigen Problemen führen. Und bei so einer Standardfunktion, die im WBB4.1 eben zum Standardumfang gehört, greife ich nicht zu einem Plugin.

    Darum wäre der für mich richtige schritt gewesen weiterhin zu filter usw, jedoch im ACP die Möglichkeit zu schaffen eigene HTML tags (und damit einhergehend auch deren Attribute) nach belieben selbst auf die whitelist zu setzen, im ideal fall mit eigener Berechtigung.

    Das fände ich ehrlich gesagt nicht optimal. Ich will vollwertiges HTML verwenden. Auch wenn ich vielleicht einige HTML Tags regelmäßig verwende, kann es ja vorkommen, dass ich mal etwas anderes nutzen will / muss und dann müsste ich das vorher erst im ACP eintragen, etc blabla. Vor allem wäre es unnötig, etwas im ACP eintragen zu müssen, wenn man es vielleicht nur ein einziges mal verwendet. Dann lieber direkt alles erlauben, damit man alle Freiheiten hat.

  • Ich habe hier noch eine relative einfache Lösung gefunden - anbei als Plugin realisiert.

    Das Plugin fügt den "HTML"-BBCode hinzu, mit dem man gezielt in z.B. Foren-Beiträgen ungefiltertes HTML nutzen kann.

    [...]

    Ich glaube, was meine Vorredner sagen wollten, aber nicht über die Lippen bekommen haben war:

    "Danke."*

    Persönliche Meinung: Kann mit dieser Lösung vorerst leben. Das liegt allen voran daran, dass zwischen [html] und [/html] keine anderen BBCodes genutzt werden können, sondern strikt HTML. Ich bin nämlich kein Freund von diesem Wischiwaschihinundhergespringe zwischen BBCode und HTML1, wie es bislang möglich war. Besser gesagt: Es1 war mit ein Hauptgrund für die Ablehnung eines BBCodes meinerseits. Mir ist eine klare Trennung in der Hinsicht einfach lieber.

    * Ich möchte anmerken, dass sich der Geschäftsführer/Fillialleiter/Whatever gerade Zeit für unser First-World-Problem genommen hat. Hätte er nicht müssen, also können wir auch einfach mal nett sein.. oder?

  • Das wäre zumindest für mich dann keine Lösung, da ich sowas nicht als Plugin installieren würde, sondern direkt von WoltLab etwas haben möchte. Sonst kann das einfach zu unnötigen Problemen führen. Und bei so einer Standardfunktion, die im WBB4.1 eben zum Standardumfang gehört, greife ich nicht zu einem Plugin.

    Deshalb sprach ich mich ja auch dafür aus dass ein vergleichbares System dass die aktuell starre struktur flexibler macht von Woltlab kommt. Denn das derzeit als plugin umzusetzen ist echtt ein Kraus, an zu vielen Stellen wird gefiltert, das fängt schon im editor an und durch die Fehlende möglichkeit im Quelltext modus das Ergebnis abzusenden hat man einfach keine guten Möglichkeiten das zu umgehen.

    Das fände ich ehrlich gesagt nicht optimal. Ich will vollwertiges HTML verwenden. Auch wenn ich vielleicht einige HTML Tags regelmäßig verwende, kann es ja vorkommen, dass ich mal etwas anderes nutzen will / muss und dann müsste ich das vorher erst im ACP eintragen, etc blabla. Vor allem wäre es unnötig, etwas im ACP eintragen zu müssen, wenn man es vielleicht nur ein einziges mal verwendet. Dann lieber direkt alles erlauben, damit man alle Freiheiten hat.

    An der Stelle kann ich persönlich nur den Kopf Schütteln. Denn das was du äußerst ist das typische Beispiel von Bequemlichket gegen Sicherheit zu tauschen.
    Versteh mich nicht falsch, aber ich kann immer wieder nur wiederholen was für ein massives Sicherheitsproblem derzeit das ungefilterte HTML darstellt. Klar kommt gleich das Argument dass man das ja immer nur vertrauenswürdigen personen zugänglich macht (aber macht das auch wirklich jeder Admin ? oder setzen nicht vll manche Admins unwissentlich einen falschen Haken ?) aber ich hab schon zu viele Communities zerbrechen gesehen wenn sich teile des Teams abspalten und genau hier liegt die Gefahr. Denn jeder mit nur ein paar Kenntnissen in sachen HTML / JS kann so massiven Schaden anrichten, Login Daten abgreifen etc. Und nun bietet Woltlab eine im Grunde sichere Möglichkeit an die man nur richtiug ausschöpfen müsste und dann soll die Sicherheit der bequemlichkeit zum Opfer fallen ?
    Sry, für mich unverständlich...

  • Das Sicherheitsargument sticht für mich nicht. Will jemand hier ernsthaft behaupten, dass es in allen bisherigen Versionen der Software ein immenses Sicherheitsproblem wegen der Möglichkeit gab, HTML in Beiträgen zu verwenden?

    @Marcel Werk: Die BBCode-Lösung ist zwar besser als garnichts, entspricht aber nicht meinen Vorstellungen von einer benutzerfreundlichen Umsetzung. Ich hatte erwartet, bei entsprechender Berechtigung unter Einstellungen die Option "HTML verwenden" vorzufinden und das dann auch uneingeschränkt tun zu können.


    Gruß norse

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

  • Das Sicherheitsargument sticht für mich nicht. Will jemand hier ernsthaft behaupten, dass es in allen bisherigen Versionen der Software ein immenses Sicherheitsproblem wegen der Möglichkeit gab, HTML in Beiträgen zu verwenden?

    Ja, war es, ich habe es auch mehrfach erwähnt und ich glaube @Bibini sogar mal genauer erläutert.
    Du kannst, etwas fachwissen vorrausgesetzt damit ohne Größere Probleme login Daten stehlen (interaktion mit dem user vorrausgesetzt) und die cockkies aller user die eine entsprechende Seite aufrufen stehlen um dich als dieser user anzumelden etc.

    Mal nen einfaches Beispiel um zu Zeigen was damit alles Möglich wird:
    <script>window.location.href = 'https://www.google.de/';</script>
    einmal eintragen und schon wird jeder user weiter geleitet.
    Lustig wird das dann wenn ich HTML in Signaturen verwenden darf und dann als ehemaliges teammember mit tausenden posts sowas in die Sig klatsche...

  • Das wurde von WL aber anscheinend über einen Zeitraum von nunmehr 15 Jahren nicht als Argument gesehen, die Funktion zu beschneiden. Insofern ist mir unbegreiflich, warum jetzt auf einmal.


    Gruß norse

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

  • Das ist nicht möglich, die Cookies werden mit HttpOnly gesetzt, wodurch diese nicht über window.cookie verfügbar sind.

    OK, ich bekenne mich schuldig, das hab ich nicht bis ins Detail angeschaut ;)
    Aber selbst wenn ich keinen Zugriff auf die coockies habe kann ich genug unsinn anstellen, z.B. fingierte Fehlermeldungen etc und das ist am ende für den admin selbst einfach kaum nachvollziehbar woran sowas liegt.

    Das wurde von WL aber anscheinend über einen Zeitraum von nunmehr 15 Jahren nicht als Argument gesehen, die Funktion zu beschneiden. Insofern ist mir unbegreiflich, warum jetzt auf einmal.

    Das ist sicher richtig, mich persönlich hat das aber schon seit Jahren gestört und ich hab es in mehreren Themen als Sicherheitslücke genannt.
    Dass sie nun geschlossen wurde finde ich super und ist einer der Gründe weshalb ich mich absolut dagegen ausspreche sie im Core direkt wieder einzubauen. Was ihr dann als Plugin selbst bei euch einbaut (und auch gerne von Woltlab stammt) ist mir ja egal, aber ohne einer Möglichkeit kontrollieren zu können was genau erlaubt ist sollte das mMn auf gar keinen Fall zurück kommen.

  • Versteh mich nicht falsch, aber ich kann immer wieder nur wiederholen was für ein massives Sicherheitsproblem derzeit das ungefilterte HTML darstellt. Klar kommt gleich das Argument dass man das ja immer nur vertrauenswürdigen personen zugänglich macht (aber macht das auch wirklich jeder Admin ?

    Wenn es ein Sicherheitsproblem ist, dem Team Zugriff auf HTML zu geben, dann dürfte man dem Team auch keine Moderatorenrechte geben und erst recht keinen Zugriff auf das ACP. Wer weiß, was die dort anstellen könnten. Das wären ja MASSIVE Sicherheitsprobleme.

    Dass man HTML nur denjenigen gibt, die im Team sind und denen man vertraut, sollte klar sein. Dann ist das auch kein Sicherheitsproblem. Zumindest nicht mehr als andere Gruppenrechte.


    Denn das was du äußerst ist das typische Beispiel von Bequemlichket gegen Sicherheit zu tauschen.

    Sicherheit tausche ich da kein Stück. Siehe den Abschnitt hier drüber. Aber Bequemlichkeit ist es. Ja. Und sowas erwarte ich von der heutigen Software und Technik. Sie muss smart zu bedienen sein und möglichst unkompliziert. Das wäre das von dir erwähnte Szenario halt nicht, wenn man jedes HTML Tag erst einzeln im ACP freigeben müsste, bevor man es nutzen kann. Das wäre weit weniger smart als im WBB4.1, also ein Rückschritt.

    Man stelle sich vor, man verfasst einen Beitrag, plötzlich kommt man auf eine Idee und es scheitert, da der HTML Code noch nicht freigegeben ist. Als man das realisiert, muss man erstmal ins ACP wechseln, gibt den Code frei und wechselt dann anschließend wieder zurück zu seinem Beitrag. Stück für Stück bearbeitet man den Beitrag weiter und am Ende entscheidet man sich doch gegen den genutzten Code, sondern löst es anders. Also wieder ins ACP und den Code deaktivieren + vielleicht den neuen Code aktivieren. Das ist absolut nicht smart.

    Man sollte zumindest die Option haben, gewissen Benutzergruppen wirklich vollständiges HTML freizugeben. Sachen, die WIRKLICH sicherheitsrelevant sind, können ja gerne gefiltert werden. Aber das trifft auf das meiste eben nicht zu. Davon abgesehen, dass das Team des Forums sowieso keinen Müll damit machen sollte.

  • Wenn es ein Sicherheitsproblem ist, dem Team Zugriff auf HTML zu geben, dann dürfte man dem Team auch keine Moderatorenrechte geben und erst recht keinen Zugriff auf das ACP. Wer weiß, was die dort anstellen könnten. Das wären ja MASSIVE Sicherheitsprobleme.

    Damit vergleichst du mal wieder Äpfel mit Birnen, denn im gegensatz zu deinem ungefilterten HTML kann ich im ACP bis ins aller kleinste detail festlegen wer welche Rechte hat, auch im ACP selbst.
    Mods haben z.B. keine Rechte zum endgültigen löschen und zusammen mit dem Bearbeitungs verlauf kann ich im Zweifels fall jeder Zeit allen Unsinn den jemand anstellen kann auch wieder zurück setzen.
    Admins mit Zugriff auf das ACP haben auch bei weiten nicht auf alles Zugriff, hier kann man super filtern was geht und was nicht.
    Und genau soetwas würde ich mir wünschen wenn man eben mit HTML arbeitet.


    Man stelle sich vor, man verfasst einen Beitrag, plötzlich kommt man auf eine Idee und es scheitert, da der HTML Code noch nicht freigegeben ist. Als man das realisiert, muss man erstmal ins ACP wechseln, gibt den Code frei und wechselt dann anschließend wieder zurück zu seinem Beitrag. Stück für Stück bearbeitet man den Beitrag weiter und am Ende entscheidet man sich doch gegen den genutzten Code, sondern löst es anders. Also wieder ins ACP und den Code deaktivieren + vielleicht den neuen Code aktivieren. Das ist absolut nicht smart.

    Dann erlaub mir die Frage, wieviele HTML Tags denkst du denn dass du so benötigst ?
    Ich mein es gibt nur eine hand voll gängiger Tags die für die meisten überhaupt in Frage kommen und alles andere ist dann so exotisch dass es ohne zusätzlichem css eh unbrauchbar wird.
    nenn mir doch einfach mal 10 Tags die du gebrauchen könntest und die aktuell nicht vom WSC unterstützt werden ?
    Und fang jetzt bitte nicht mit sebst erstellten html5 tags an, damit kann man sich klar ne unendliche Anzahl erzeugen, aber wirklich realistische Einsatzzwecke gibt es kaum.

    Ich erkenne derzeit vor allem den Mangel an html kommentaren, divs und iframes an (das waren jene Elemente die in der Beta zu tage traten), also kann nicht die Rede davon sein ständig ins ACP zu müssen.
    Ein "ich will alles mögliche weil ich könnts ja irgendwann mal eventuell brauchen" sehe ich nun nicht wirklich als Argument dagegen an...


    Sachen, die WIRKLICH sicherheitsrelevant sind, können ja gerne gefiltert werden.

    Das ist das Problem, wo beginnt bei dir Sicherheitsrelevant und wo endet es ?
    Iframes kann man z.B. auch super missbrauchen um userdaten abzugreifen ohne dass diese das bemerken.
    Willst du die auch Filtern ?
    Und wo ist dann schluss ?
    Ich mein dann meckern alle dass zuviel gefiltert wird und sie keinen Einfluss darauf haben, dann lieber ein flexibles system bei dem man das zumindest selbst entscheiden kann...

  • Damit vergleichst du mal wieder Äpfel mit Birnen, denn im gegensatz zu deinem ungefilterten HTML kann ich im ACP bis ins aller kleinste detail festlegen wer welche Rechte hat, auch im ACP selbst.
    Mods haben z.B. keine Rechte zum endgültigen löschen und zusammen mit dem Bearbeitungs verlauf kann ich im Zweifels fall jeder Zeit allen Unsinn den jemand anstellen kann auch wieder zurück setzen.
    Admins mit Zugriff auf das ACP haben auch bei weiten nicht auf alles Zugriff, hier kann man super filtern was geht und was nicht.
    Und genau soetwas würde ich mir wünschen wenn man eben mit HTML arbeitet.

    Wieso vergleiche ich da Äpfel mit Birnen? Ob jemand das Recht hat vollständiges HTML zu nutzen oder das Recht hat im ACP Benutzer zu löschen oder zu bearbeiten oder im Forum Beiträge (komplett) zu löschen. Das wäre laut dir dann ja alles ein Sicherheitsrisiko, da der Admin / Moderator damit Müll machen könnte. Trotzdem gibt es eben Leute aus dem Team, denen man das erlaubt. Vielleicht nicht jedem, aber dafür gäbe es ja Gruppenrechte, um zu bestimmen, wer HTML nutzen kann und wer nicht.

    Dann erlaub mir die Frage, wieviele HTML Tags denkst du denn dass du so benötigst ?

    Es ist doch völlig egal, wie viele HTML Tags ich benötige. Oder willst du jetzt argumentieren, dass dein Szenario bei bis zu 5 Tags gut ist und es erst bei über 10 Tags anders geregelt werden müsste? Unpraktisch bleibt unpraktisch. Egal bei wie vielen Tags. Es mag ja sein, dass dein Vorschlag für andere Leute passt. Für mich allerdings nicht. Ich sehe keinen Grund, die Tags zu begrenzen und es unnötig kompliziert zu machen.

    Ein "ich will alles mögliche weil ich könnts ja irgendwann mal eventuell brauchen" sehe ich nun nicht wirklich als Argument dagegen an...

    Musst du ja auch nicht als Argument ansehen. Für mich ist es aber trotzdem eins.

    Das ist das Problem, wo beginnt bei dir Sicherheitsrelevant und wo endet es ?
    Iframes kann man z.B. auch super missbrauchen um userdaten abzugreifen ohne dass diese das bemerken.
    Willst du die auch Filtern ?
    Und wo ist dann schluss ?
    Ich mein dann meckern alle dass zuviel gefiltert wird und sie keinen Einfluss darauf haben, dann lieber ein flexibles system bei dem man das zumindest selbst entscheiden kann...

    Das kann ich so nicht beurteilen, aber Iframes würde ich persönlich eigentlich zulassen. Auch wenn ich sie bisher noch nicht gebraucht habe. Solang da kein Müll gemacht wird, passt ja aber alles. Und Zugriff hätte ja eh nur das Team, dem man HTML gezielt freigibt und nicht jeder 0815 User.

    Aber von mir aus soll man halt zur Not Abstufungen als Gruppenrecht einbauen, zwischen denen man wählen kann + irgendwie auflisten, welche Tags von welcher Einstellung betroffen sind.

    • Kann rudimentäres HTML nutzen (quasi aktueller Zustand)
    • Kann sicheres HTML nutzen
    • Kann sämtliches HTML nutzen

    Und Dinge wie Iframes würde man dann halt erst durch die Einstellung "Kann sämtliches HTML nutzen" freischalten. Ich denke das wäre ein guter Kompromiss.

    Edited 3 times, last by ReeN (November 23, 2016 at 4:27 PM).

  • Wieso vergleiche ich da Äpfel mit Birnen? Ob jemand das Recht hat vollständiges HTML zu nutzen oder das Recht hat im ACP Benutzer zu löschen oder zu bearbeiten oder im Forum Beiträge (komplett) zu löschen. Das wäre laut dir dann ja alles ein Sicherheitsrisiko, da der Admin / Moderator damit Müll machen könnte.

    Es ist auch ein Sicherheits Risiko und ich hab bisher in 2 Foren dabei helfen dürfen die Suppe wieder auszulöffeln da ehemalige Teammitglieder genau das getan haben. Es ist eine Riesen Arbeit sowas wieder gerade zu biegen (im letzten falle durfte ich gut 20k Posts mit den dazugehörigen Themen und mehrere hundert User wieder aus nem ne woche alten Backup wiederherstellen) und in beiden Foren wird seitdem verhindert dass andere aus dem Team soetwas nochmals wiederholehn können. Und genau das lässt sich eben gut über Gruppenrechte lösen ;)


    Es ist doch völlig egal, wie viele HTML Tags ich benötige. Oder willst du jetzt argumentieren, dass dein Szenario bei bis zu 5 Tags gut ist und es erst bei über 10 Tags anders geregelt werden müsste? Unpraktisch bleibt unpraktisch. Egal bei wie vielen Tags. Es mag ja sein, dass dein Vorschlag für andere Leute passt. Für mich allerdings nicht. Ich sehe keinen Grund, die Tags zu begrenzen und es unnötig kompliziert zu machen.

    Mein Argument bezieht sich darauf dass du im Normalfall einfach nicht wie von dir behauptet einen riesen Verwaltungsaufwand hast sondern du normalerweise nur einmal die paar fehlenden tags einträgst und danach dann ruhe hast.
    Dass die Tags die man benötigt von Forum zu Forum unterschiedlich sind steht auser frage, darum sollte man das eben konfigurieren können.

    Kann nur sicheres HTML nutzen

    Und was ist sicheres HTML ?
    Aktuell ist es sicher, aber hier wurde ja mehr gewünscht, woran machst du dann also den Unterschied zum aktuellen stand der dinge fest ?

    Am ende dreht sich die Diskussion nur im Kreise, ich als Admin und Techniker in verschiedenen Foren hab eben schon zuoft mitbekommen das alles was man missbrauchen kann früher oder später auch missbrauchen wird um noch an ein "wird schon alles gutgehen" zu glauben.
    Dass es bei dir bisher nicht passiert ist freut mich, aber überlege nur mal einen Augenblick ob es dir das Risiko dass es passieren könnte wirklich Wert ist^^

  • Es ist auch ein Sicherheits Risiko und ich hab bisher in 2 Foren dabei helfen dürfen die Suppe wieder auszulöffeln da ehemalige Teammitglieder genau das getan haben. [...] und in beiden Foren wird seitdem verhindert dass andere aus dem Team soetwas nochmals wiederholehn können. Und genau das lässt sich eben gut über Gruppenrechte lösen

    Das könnte man beim HTML ja auch. Gezielt sagen, welche Gruppe HTML nutzen darf. Dann gibt man dem restlichen Team dieses Recht eben nicht, wenn man da bedenken hat. Quasi das selbe wie bei allen anderen Gruppenrechten. Deshalb braucht man HTML jetzt aber nicht aufzusplitten in jedes einzelne HTML Tag.

    Mein Argument bezieht sich darauf dass du im Normalfall einfach nicht wie von dir behauptet einen riesen Verwaltungsaufwand hast sondern du normalerweise nur einmal die paar fehlenden tags einträgst und danach dann ruhe hast.
    Dass die Tags die man benötigt von Forum zu Forum unterschiedlich sind steht auser frage, darum sollte man das eben konfigurieren können.

    Normalerweise, vielleicht, hätte, könnte, sollte, etc blabla. Ja. Aber es kann eben auch so sein, dass man nicht alle Tags freigeschaltet hat und dann nochmal dran basteln muss und das ist einfach unnötig, wenn man sowieso vollständiges HTML möchte. Und genau das möchte ich. Vielleicht verstehst du, dass mir deine Variante deshalb nicht genügen würde. Wenn es dir genügen würde, ist das top, aber mir eben nicht.

    Und was ist sicheres HTML ?

    Das würde ich dann WoltLab überlassen. Solang man eine Auswahl hat, wie z.B. "rudimentär -> sicher -> unsicher" wäre es mir egal, was wie eingestuft wird, da ich es ja so oder so den gewünschten Benutzergruppen freigeben könnte.

    Aktuell ist es sicher, aber hier wurde ja mehr gewünscht, woran machst du dann also den Unterschied zum aktuellen stand der dinge fest ?

    Da hatte ich ja "rudimentäres HTML" und "sicheres HTML" als Abstufung im Gruppenrecht vorgeschlagen. Rudimentär ist der aktuelle Stand. Also nur sehr abgespecktes HTML. Sicheres HTML erweitert das um alles, was noch als sicher eingestuft ist.

    [...] aber überlege nur mal einen Augenblick ob es dir das Risiko dass es passieren könnte wirklich Wert ist^^

    Mit dieser Einstellung dürfte ich dem Team wie gesagt überhaupt keine Rechte geben, da mit allem irgendwie Müll gemacht werden könnte und das deshalb alles ein Risiko wäre. Deshalb: Ja, es wäre mir das Risiko wert. Genau so wie es mir das Risiko wert ist, wenn ich jemandem andere Rechte gebe. Wer das Recht HTML zu nutzen kriegen würde, könnte man ja immer noch selbst entscheiden. Also sehe ich da kein Problem. Wer es als Risiko ansieht, der verteilt das Recht einfach nicht und fertig.

  • Gezielt sagen, welche Gruppe HTML nutzen darf. Dann gibt man dem restlichen Team dieses Recht eben nicht, wenn man da bedenken hat. Quasi das selbe wie bei allen anderen Gruppenrechten. Deshalb braucht man HTML jetzt aber nicht aufzusplitten in jedes einzelne HTML Tag.

    Das Problem ist eben, dass ich durchaus selbst den bedarf sehe das ganze finetunen zu können.
    In einem aktuellen Beispiel ist es z.B. so das ich für eine Community ne Möglichkeit schaffen sollte tabellen auf gewisse Art stylen zu können (konkret ging es um rahmen usw die über entsprechende css klassen vergeben werden).
    Im wbb4 musste ich dafür nen extra bbcode erstellen (mit einer entsprechenden klasse die alles validiert und als sicher einstuft) und mit einer entsprechenden Möglichkeit das im ACP zu verwalten wäre das ganze mit wenigen Klicks möglich.
    Derzeit müsste ich entweder wieder auf den bbcode zurückgreifen (was dann wieder doof im Editor wirkt weil man dann html und bbcodes mischen muss) oder aber ich muss via Plugin entsprechende Regeln im Purifier einbauen.

    Mit dieser Einstellung dürfte ich dem Team wie gesagt überhaupt keine Rechte geben, da mit allem irgendwie Müll gemacht werden könnte und das deshalb alles ein Risiko wäre. Deshalb: Ja, es wäre mir das Risiko wert. Genau so wie es mir das Risiko wert ist, wenn ich jemandem andere Rechte gebe. Wer das Recht HTML zu nutzen kriegen würde, könnte man ja immer noch selbst entscheiden. Also sehe ich da kein Problem. Wer es als Risiko ansieht, der verteilt das Recht einfach nicht und fertig.

    Das tun sie auch meist nicht, anstatt erst mal Zugriff auf alles zu vergeben gehe ich den umgekehrten weg und vergebe Rechte nach Bedarf.
    User werden nicht via ACP gelöscht sondern nur gebannt, will ein user gelöscht werden kann er das selbst im Profil tun. Und nen bann kann man einfach wieder aufheben wenn man mitbekommt dass jemand Unsinn anstellt ;)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!