Erlaubte HTML Tags nach Update

[elwega]

Guten Tag zusammen,
kann es sein, dass bei einem Update über den CM bei den erlaubten HTML Tags <script> rausfliegt.
Contao 4.8.4
Das habe ich zumindest soeben festgestellt, nach einem Kundenhinweis, dass seit gestern ein eingebundenes Widget nicht mehr funktioniert.
Bei der Fehlersuche ist aufgefallen, dass <script> nicht mehr in den Tags vorhanden war.
Leider funktioniert das Widget nun auch nicht mehr mit neu hinzugefügten <script> Tag.
Wie kann man vehindern, dass erlaubte HTML Tags automatisch geändert werden.

[mlweb]

Die erlaubten Tags stehen doch in der localconfig.php. Die wird beim normalen Update doch gar nicht angefasst.
Wie hast Du denn das Update gemacht? Beim Update in der Parallelinstallation muss diese Datei auch übertragen werden.

[webstar]

Guten Tag zusammen,
kann es sein, dass bei einem Update über den CM bei den erlaubten HTML Tags <script> rausfliegt.
Contao 4.8.4
Das habe ich zumindest soeben festgestellt, nach einem Kundenhinweis, dass seit gestern ein eingebundenes Widget nicht mehr funktioniert.
Bei der Fehlersuche ist aufgefallen, dass <script> nicht mehr in den Tags vorhanden war.
Leider funktioniert das Widget nun auch nicht mehr mit neu hinzugefügten <script> Tag.
Wie kann man vehindern, dass erlaubte HTML Tags automatisch geändert werden.

Nein, das ist nicht so (zumindest mit einem Standard Contao). Lässt sich das reproduzieren, dass der Eintrag aus der localconfig.php / app/config/config.yml entfernt wird?

Meine Vermutung: Der entsprechende Eintrag wurde entfernt/nicht übernommen.

[mlweb]

In /app/config/config.yml bzw. /config/config.yml können die Einträge aber eigentlich nur sein, wenn sie dort manuell eingetragen werden. Werden Sie im Backend eingetragen landen sie doch noch immer in der localconfig.php.

Leider funktioniert das Widget nun auch nicht mehr mit neu hinzugefügten <script> Tag.

Wer hat eigentlich die "Oberhand", wenn der Eintrag manuell in der config.yml eingetragen wird und über die Einstellungen in die localconfig.php?

[elwega]

In /app/config/config.yml bzw. /config/config.yml können die Einträge aber eigentlich nur sein, wenn sie dort manuell eingetragen werden. Werden Sie im Backend eingetragen landen sie doch noch immer in der localconfig.php.

Wer hat eigentlich die "Oberhand", wenn der Eintrag manuell in der config.yml eingetragen wird und über die Einstellungen in die localconfig.php?

Das weis ich auch nicht wer die hat

Danke Euch allen für die Antworten, aber zu den vorherigen Antworten.
Ich habe eigentlich nichts irgendwo eingetragen oder geändert in keiner config.yml oder sonstwo.

Die Seite wurde von der letzten 3er Version schon vor Monaten auf die 4 gehoben, übrigens problemlos (Contao halt)
Die erlaubten TAGs sind nur in den Einstellungen eingetragen gewesen.
Muss man diese nun in die config.yml eintragen damit sie nicht durch irgendwas geändert werden?

Meine Vermutung: Der entsprechende Eintrag wurde entfernt/nicht übernommen.

das könnte sein, ist aber nicht mehr nachvollziehbar.
Soll man sicherheitshalber die Einstellung in die config.yml eintragen?

[mlweb]

Nein die localconfig.php reicht vollkommen aus.
Dort werden sie bei Updates auch nicht angefasst/verändert.

Die Frage mit der "Oberhand" ging eher an @webstar .

[elwega]

ok, wobei die Oberhand wirklich nicht immer klar erscheint
Die localconfig wurde vermutlich schon beim Update auf 4 nicht mit übertragen.
Das bedeutet aber, dass der Eintrag in den BE Einstellungen nicht als sicher angesehen werden kann und eine Eintragung in die Konfigurationsdateien von Hand erfolgen muss oder sehe ich das jetzt total falsch?

[webstar]

In /app/config/config.yml bzw. /config/config.yml können die Einträge aber eigentlich nur sein, wenn sie dort manuell eingetragen werden. Werden Sie im Backend eingetragen landen sie doch noch immer in der localconfig.php.

Wer hat eigentlich die "Oberhand", wenn der Eintrag manuell in der config.yml eingetragen wird und über die Einstellungen in die localconfig.php?

Die Konfiguration in der config.yml greift meines Wissens überschreibend.

[mlweb]

Ich selbst habe noch nie Einträge dieser Art in die config.yml vorgenommen.
Ich kann Dir dazu leider nur sagen, dass ich weiss das man einige dieser Einträge unter bestimmten Bedingungen auch dort vornehmen kann.
Ist aber m.E. eher eine spezielle Geschichte, die einige Entwickler verwenden.
Wenn die relevanten Inhalte der localconfig.php beim Update von Contao 3 auf Contao 4 nicht übernommen wurden, dann wird das Problem eher darin liegen.

[elwega]

Hallo,
ist mittlerweile soweit klar.
Was aber noch nicht klar ist, ob die Einstellung im BE reicht oder ob es noch zusätzlich in eine der Konfig- Dateien geschrieben werden muss.
Nach meinem Verständnis sollten doch die Eintragungen im BE bindend sein und dürften nicht geändert werden.

[mlweb]

Die Einstellung im Backend reicht bei einer normalen Installation aus.
Hast Du nach der Veränderung den Cache gelöscht.

[webstar]

Was aber noch nicht klar ist, ob die Einstellung im BE reicht oder ob es noch zusätzlich in eine der Konfig- Dateien geschrieben werden muss.

Die Einstellung im Backend reicht. Ich habe dies nur ergänzend erwähnt, da es als Ursache für die Verhaltensweise in Betracht kam.

[elwega]

OK danke,
im BE bei Sicherheitseinstellungen war das TAG ganz sicher drinn, denn das Widget hat ja einige Zeit funktioniert.
Warum das TAG dort rausgeflogen ist hat mich irritiert, rausgenommen hat das ganz sicher keiner.
Ich kontrolliere eigentlich nach Updates CM immer ob alles funktioniert, aber nie alle möglichen Stellen im BE
Jetzt ist das TAG wieder drinn und ich warte auf Rüclinfo des Med- Dienstes ob mit deren Widget etwas passiert ist.
Mal sehen...

[webstar]

im BE bei Sicherheitseinstellungen war das TAG ganz sicher drinn, denn das Widget hat ja einige Zeit funktioniert.

Das es funktioniert hat, besagt nur, dass es zum Zeitpunkt, als das Widget angelegt wurde, das Script-Tag erlaubt war. Dass es nicht mehr funktioniert, besagt, dass es jemand bearbeitet hatte. Contao verwendet noch immer eine Input-Enkodierung. Was erst einmal in der DB steht wird als sicher angenommen und ausgespielt.

Warum das TAG dort rausgeflogen ist hat mich irritiert, rausgenommen hat das ganz sicher keiner.

Ich wiederhole und konkretisiere meine Vermutung: Bei einem Update von Contao 3 auf Cotnao 4 wurden die Einstellungen nicht übernommen.

Jetzt ist das TAG wieder drinn und ich warte auf Rüclinfo des Med- Dienstes ob mit deren Widget etwas passiert ist.

Nachdem das TAG wieder erlaubt ist, muss auch der ehemalige Script-Tag entfernt und erneut eingetragen werden. Die <>-Tag Zeichen sind enkodiert. Contao verwendet ja immer noch eine Input-Enkodierung.

[elwega]

Hi mlweb,

danke für den Tipp. Ich habe alles was damit zu tun hat gelöscht, den Cache auch, dann das Script neu als eigenes HTML eingefügt in die Seite (ohne Tippfehler ).
Im Quelltext wir das Script auch richtig angezeigt ohne Quotes oder fehlende Zeichen, nur es wird nicht ausgführt.
Lediglich der Schluss- Teil der nur einen Link auf das Rechenzentrum enthält erscheint.
Jetzt erhärtet sich bei mir die Vermutung, dass es am Script bzw. dessen Aufruf liegt.
Vielleicht hat sich da etwas geändert und es wurde nicht kommuniziert.
Vom Med- Rechenzentrum ist noch kine Antwort gekommen. Ich warte noch den halben Vormittag ab dann rufe ich dort an.

[Stefko]

Moin,

Ich selbst habe noch nie Einträge dieser Art in die config.yml vorgenommen.
Ich kann Dir dazu leider nur sagen, dass ich weiss das man einige dieser Einträge unter bestimmten Bedingungen auch dort vornehmen kann.
Ist aber m.E. eher eine spezielle Geschichte, die einige Entwickler verwenden.

Der Weg geht aber ganz eindeutig in diese (config.yml) Richtung, also, dass diese die localconfig ablösen wird. Grund ist wohl, dass Contao ja selbst "nur" noch ein Symfony-Bundle ist (neben entsprechend vielen anderen) und diese eben per config.yml konfiguriert werden (müssen).
Ein bisschen Erklärung findet sich auch hier https://docs.contao.org/manual/de/sy...en/#config-yml
Gerade die unterschiedlichen Konfigurationen für Test- bzw. Produktionsumgebung finde ich ganz interessant.

[mlweb]

@Stefko Der Weg schon. Nur wenn Otto-Normalnutzer heute seine Einstellungen im Backend macht, dann landen sie nach wie vor in der localconfig.php.
Da beim TO ja die Änderungen nicht gegriffen hatten, stand natürlich auch die Frage im Raum, ob es eine config.yml mit eventuell anderen Einträgen gibt, die die localconfig.php "überschreiben".

[elwega]

Hallo zusammen und danke fürs mit überlegen!
das steht in der localconfig:

$GLOBALS['TL_CONFIG']['allowedTags'] = '<a><abbr><acronym><address><area><article><aside><audio><b><bdi><bdo><big><blockquote><br><base><button><canvas><caption><cite><code><col><colgroup><data><datalist><dataset><dd><del><dfn><div><dl><dt><em><fieldset><figcaption><figure><footer><form><h1><h2><h3><h4><h5><h6><header><hgroup><hr><i><img><input><ins><kbd><keygen><label><legend><li><link><map><mark><menu><nav><object><ol><optgroup><option><output><p><param><picture><pre><q><script><s><samp><section><select><small><source><span><strong><style><sub><sup><table><tbody><td><textarea><tfoot><th><thead><time><tr><tt><u><ul><var><video><wbr>';

unter "app/config/" gibt es die parameters.yml darin ist nichts ausser database Daten.

[Stefko]

Nur wenn Otto-Normalnutzer heute seine Einstellungen im Backend macht, dann landen sie nach wie vor in der localconfig.php.

Mein Fehler, ich dachte die 4.8 würde auch schon "von sich aus" die config.yml anstatt der localhost nutzen