Text Editor "bereinigt" Quellcode und entfernt Bilder (img-Element)

Eigentlich tut der Editor genau das, was er soll: Jeden Input zuzulassen, stellt ein Sicherheitsrisiko dar. Man kann sich aber individuell behelfen:

Über diese Konfigurationsdatei kann auch der HTML-Sanitizer angepasst werden. Um z.B. Bilder zuzulassen, müsste die basic rule angepasst werden. So können für die Felder spezielle Regelsätze angewendet werden:

name: product_translation.description
sets: ["basic", "media"]

Dies würde die Grundregeln + Bilder für die Produktbeschreibung ermöglichen. Wenn dies nicht angegeben wird, wird nur der Grundregelsatz verwendet.

Um das auch für CMS-Elemente so abbilden zu können:

name: text_cms_element
sets: ["basic", "media"]

müssen wir nochmal ran, haben das aber auf dem kurzfristigen Schirm :wink:

Ich hoffe, das hilft erstmal weiter.

6 „Gefällt mir“

Danke für die Antwort, aber genau diese Art der zunehmenden übergriffigen Bervormundung weitet sich echt zur Pest aus. Das scheint sich eine Generation echt fett auf die Fahnen geschrieben zu haben.

Shopbetreiber sind erwachsene Menschen, was soll da diese Bervormundung aus dem grünen Münsterland? Ein Simples Config-Feld im Backend, was erlaubt ist, und was nicht - schon sind alle glücklich.

5 „Gefällt mir“

Mach mal halblang. Das ist ein simples Sicherheitsfeature, das wohl mittlerweile in jedem beliebigen CMS mit Texteditor verwendet wird, mit „Bevormundung“ hat das überhaupt nichts zu tun. Wenn man groß und erwachsen ist und weiss was man tut, kann man für sich selbst entscheiden, ob man es gern deaktivieren möchte.

Geben wir es komplett ungesichert raus, bekommen wir auf die Mütze, wenn dadurch eine Attacke gefahren wurde. Das möchte dann sicher auch niemand.

Beste Grüße aus Leipzig :wink:

Wir reden vom Backend und nicht vom Frontend, in dem unbekannte Kunden „Daten“ eingeben.

Wenn mir also einer über die HTML-Felder im Backend etwas „böses“ unterjubeln will, habe ich schon wesentlich früher ein Problem, nämlich jenes, dass schon ein unbefugter - mir schaden wollender - im Backend ist.

In Schöppingen hat jemand entschieden, was gut für mich ist - also wird einfach mal alles in den Feldern verboten. Genau das ist für mich Bevormundung!

Wenn ich extra den „Code-Editor“ im HTML-Editor aktiviere, werde ich mir schon etwas dabei denken. Dann kann man sich den Button auch gleich sparen! Könnte man auch über Rollen regeln.

Aber irgend eine yaml-Datei zu editieren, die vermutlich nach jedem Update wieder zurückgesetzt ist, mag eine Notlösung sein, mehr aber auch nicht. :wink:

Wie geschrieben: Dafür ein Danke

Wenn ich in Wordpress den „HTML-Modus“ benutze, wird auch nicht sofort wieder „gesäubert“. :wink:

Und dem Link/Ticket von der Moorleiche kann man ja entnehmen, dass die „Problematik“ keinesfalls jetzt aus heiterem Himmel gekommen ist - sondern weggewischt wurde.

4 „Gefällt mir“

Im sonnigen Mountain View hat vor Jahren jemand für Dich entschieden, dass http nicht mehr genutzt werden sollte… :wink:

1 „Gefällt mir“

Es liegt ja trotzdem in der Verantwortung des Shopbetreibers und dieser haftet auch für seinen Shop. Ist ja genauso bei Cookies/Externe Resources usw. Wenn man JavaScript entfernt, macht das durchaus Sinn. Alles Andere aber eher weniger. Eine optionale Einstellung im Admin, welches der Admin-User verwalten kann, reicht vollkommen aus. So wie es aktuell ist - eher schlecht als Recht - betrifft ja nicht nur den Texteditor sondern jegliche Art von HTML Content.

4 „Gefällt mir“

Super, damit hat man ja erstmal kurzfristig einen Workaround und kann erstmal weitermachen.

Leider funktioniert die von dir beschriebene Änderung bei mir (6.5) nicht. Ich habe die shopware.yaml unter: /vendor/shopware/core/Framework/Resources/config/packages angepasst, sieht dann so aus

fields:
            - name: product_translation.description
              sets: ["basic", "media"]
            - name: app_cms_block.template
              sets: ["basic", "media", "tidy"]
            - name: snippet.value
              sets: ["basic", "media", "bootstrap"]
            - name: text_cms_element
              sets: ["basic", "media"]

Das text_cms_element Pseudo-Feld gibt es noch nicht. Ist nur der Plan, wie man speziell Regeln für das CMS Element aufstellen können soll. Die CMS Elemente nutzen zur Zeit alle das basic Rule-Set. Daher muss man das jetzt noch generell anpassen.

Wenn zB zusätzlich überall das img Tag erlaubt werden soll kann man das hier unter config/packages/shopware.yml eintragen (falls die noch nicht existiert, einfach anlegen). Die wird auch bei einem Update nicht überschrieben, sondern das ist der gängige Weg, um tiefgreifendere Einstellungen am System vorzunehmen.

shopware:
  html_sanitizer:
    sets:
      - name: basic
        tags: ["img"]
        attributes: ["src", "alt"]

Man kann darüber prinzipiell alles erlauben. Es gibt ein paar Sonderfälle wie script Tags oder iframes. Da muss man dann ggf zusätzliche Optionen am Set setzen. Das sind die von der HTML Purifier Library und die sind hier dokumentiert, falls es nötig sein sollte.

7 „Gefällt mir“

Hallo @dneustadt,

mit Bilder lassen sich nach der Anpassung der shopware.yml-Datei nun einfügen. Danke
Ich möchte noch span-Elemente mit einer Id einfügen, leider werden diese wieder automatisch bereinigt, obwohl ich die Datei wie folgt angepasst habe:

shopware:
  html_sanitizer:
    sets:
      - name: basic
        tags: ["img", "span"]
        attributes: ["src", "alt", "id"]

Was mache ich hier falsch?

Viele Grüße
Tom

Gehe ich recht in der Annahme, dass danach mit build-administration.sh der Adminbereich neu erstellt werden muss?
Dann ist das leider keine Lösung für die vielen kleinen Shops bei All-Inkl. und anderen Shared-Hostern, weil auch auf console node npm etc. nicht zur Verfügung stehen.

Ohne es zu wissen, aber das ist ja nichts was JS filtert, sondern eine PHP-Funktion im Core. Daher ist es eher unwahrscheinlich. Config files benötigen in der Regel nur ein leeren des Caches.

1 „Gefällt mir“

HTML Purifier verbietet by default die Verwendung von dem id Attribute, da diese nach den HTML Konventionen eindeutig auf einer Seite sein müssen und ungefilterter User-Input diese Vorgabe nicht einhalten könnte. Daher muss man die Ausnahme der Regel über das Flag Attr.EnableID einschalten.

shopware:
  html_sanitizer:
    sets:
      - name: basic
        tags: ["img", "span"]
        attributes: ["src", "alt", "id"]
        options:
          - key: Attr.EnableID
            value: true
2 „Gefällt mir“

Cache geleert - nichts. Tut es bei mir so nicht :wink:
Dafür hat der sanitizer beim Test mal wieder nicht nur das img-tag entfernt, sondern gleich wieder den gesammten Inhalt.

Ich glaube ich spinne! Eben fällt mir auch auf, dass alle Versuche einen HTML-Element eine ID zu vergeben von diesem Wunder-Editor einfach gelöscht werden. Als Shopbetreiber sollte mir doch überlassen sein, was ich dort eintrage. „id“ und „class“ sind elementare Mittel um ein HTML-Element gezielt mit CSS zu stylen. Gleiches betrifft übrigens auch „data“ Attribute. Stattdessen muss der Shopbetreiber irgendwelche Krücken in die shopware.yml einsetzen, damit das Ganze funktioniert. Geht garnicht.

Total geil, beim Versuch mit „data“ Attributen im Editor zu arbeiten:

Error 500

User Warning: Global attribute 'data' is not supported in any elements (for information on implementing this, see the support forums)

Hallo,

auf was basiert deine Aussage? Beispielsweise bei All-Inkl im Tarif „All-Inkl Premium“, der für einen (produktiven) Shop das Minimum sein sollte, kann man problemlos ein Administration- und Storefront-Build über die entsprechenden Shell-Skripte auf der Konsole ausführen. Man muss einfach vor der Ausführung der Befehle noch schnell nodejs bzw. npm per Konsole installieren, dann gehen auch die Befehle.

Viele Grüße
Sebastian

Hat funktioniert, Dankeschön!

Ich musste aber die id’s nochmal anpassen, id=„test-cat-topseller“ wurde z.B. bereinigt, id=„top“ funktioniert aber ohne Probleme.

business
endet mit

Cannot check extensions for required npm installations as jq is not installed
bin/build-administration.sh: line 53: npm: command not found

Ja, das mit dem Nachinstallieren von node und npm habe ich schon auf dem Schirm. Suche nur noch eine brauchbare Anleitung dazu.

laut max_shop und dem „gefällt mir“ darauf von dneustadt müsste es auch ohne build gehen - tuts bei mir aber nicht.

Hallo,

genau, im Prinzip sagt die Fehlermeldung ja aus, dass nodejs bzw. npm (noch) nicht installiert ist.

Wenn man sich aber einfach ein nodejs-Verzeichnis erstellt, darin per wget von nodejs. org Version 18.16 holt, das entpackt, über ein echo und den export-Befehl die Variable PATH auf user_bashrc setzt und danach noch per source die Datei ausführt, klappen beide Konsolenbefehle problemlos.

Grüße
Sebastian

Hatte ich schon gemacht: „GLIBC_2.28 not found“.
Dann gelöscht, nvm installiert und dann node stable via nvm
wieder "GLIBC_2.28 not found’

Aber das gehört jetzt nicht weiter in „dieses“ Thema :wink:

ab node 18 kommt der Fehler
node 18 ist systemvoraussetzung für SW 6.5.x

Mal beiseite legen - am 12.06.2023 hat all-inkl. für uns eine Serveraktualisierung angekündigt (dann auch MariaDB) - mal gucken, ob ubuntu dann nicht mehr meckert :wink: