Neu Geschweifte Klammern in Rich Text Feldern bei Quellcode-Eingabe zwangsweise in andere Zeichen umgewandelt => verhindert iframe-Anzeige

[Aut_ocean]

Guten Tag,
die Überschrift enthält im Prinzip schon das Problem. Bei Eingabe von Quellcode über die entsprechende Funktion in Rich Text Feldern im Onsite Composer werden geschweifte Klammern anscheinend zwangsweise in andere Zeichen umgesetzt (%7A, %7B und so weiter). Dadurch können zB iframes nicht geladen werden, der diese geschweiften Klammern im Code hat.

Ist das ein Bug? Als Nicht-Programmierer ist es für mich schwierig, die Stelle im Quellcode direkt in der Datei zu ändern. Unklar auch, ob das dann bei Updates etc. wieder überschrieben wird.

Danke fürs Feedback schonmal im voraus.

Gruß, Stefan

 

[Aut_ocean]

Inzwischen habe ich vom JTL-Support die Auskunft erhalten, dass die korrekte Umsetzung der Zeichen "{" (geschweifte Klammer) und "}" in Code %7B und %7D ist. Das wundert mich, denn diese Umsetzung führt eben dazu, dass das iframe nicht geladen werden kann. Da es ein kommerzielles iframe ist, das vielfach verwendet wird, nur eben im JTL Shop nicht funktioniert, bin ich etwas ratlos.

 

[mastertango]

ich berkomme überhaupt kein iframe über das RichText Feld gesetzt

 

[Aut_ocean]

ich berkomme überhaupt kein iframe über das RichText Feld gesetzt

Mit welchem Element bekommst Du es denn gesetzt?

 

[mastertango]

ich bekomme es garnicht gesetzt

 

[OliverS]

Inzwischen habe ich vom JTL-Support die Auskunft erhalten, dass die korrekte Umsetzung der Zeichen "{" (geschweifte Klammer) und "}" in Code %7B und %7D ist. Das wundert mich, denn diese Umsetzung führt eben dazu, dass das iframe nicht geladen werden kann. Da es ein kommerzielles iframe ist, das vielfach verwendet wird, nur eben im JTL Shop nicht funktioniert, bin ich etwas ratlos.

Das hat keinen Einfluss darauf, ob ein IFrame geladen werden kann, das ist ganz normales URL-Encoding. Was vermutlich eher das Problem ist, ist die Content Security Policy (CSP) oder das Cross-Origin Resource Sharing (CORS) beim jeweiligen Hoster. IFrames von anderen Webseiten einbinden, ist in der Regel aus Sicherheitsgründen nicht so ohne weiteres erlaubt. Ich bin allerdings kein Hosting-Experte und kann nicht sagen, wie CSP und CORS auf beiden Seiten konfiguriert sein müssen, damit das funktioniert.

 

[sebjo82]

Das hat keinen Einfluss darauf, ob ein IFrame geladen werden kann, das ist ganz normales URL-Encoding. Was vermutlich eher das Problem ist, ist die Content Security Policy (CSP) oder das Cross-Origin Resource Sharing (CORS) beim jeweiligen Hoster. IFrames von anderen Webseiten einbinden, ist in der Regel aus Sicherheitsgründen nicht so ohne weiteres erlaubt. Ich bin allerdings kein Hosting-Experte und kann nicht sagen, wie CSP und CORS auf beiden Seiten konfiguriert sein müssen, damit das funktioniert.

wenn es via csp blockiert wird, kann man es ja leicht in den dev-tools von chrome oder firefox als fehlermeldung sehen

 

[Aut_ocean]

Das hat keinen Einfluss darauf, ob ein IFrame geladen werden kann, das ist ganz normales URL-Encoding. Was vermutlich eher das Problem ist, ist die Content Security Policy (CSP) oder das Cross-Origin Resource Sharing (CORS) beim jeweiligen Hoster. IFrames von anderen Webseiten einbinden, ist in der Regel aus Sicherheitsgründen nicht so ohne weiteres erlaubt. Ich bin allerdings kein Hosting-Experte und kann nicht sagen, wie CSP und CORS auf beiden Seiten konfiguriert sein müssen, damit das funktioniert.

Vielen Dank für die Antwort! Dass die geschweiften Klammern bzw. deren Umsetzung in %7B und %7D die Ursache sein sollen, war die Erklärung der Seitenbetreiber, die den iframe Code zur Verfügung stellen. Dieser Code wird dort verkauft, um die Seite einbinden zu können, somit gehe ich davon aus, dass deren CSP/CORS das Einbinden erlauben sollte. Dann bleibt noch meine Seite, also das Shop- Hosting, das ich bei JTL gebucht habe... ich habe einen Dienstleister zu Rate gezogen und werde über den Ausgang berichten.

 

[ple]

Hätte ein ähnliches Problem, denke da ist der Editor schuld oder so.
Mein Code wir auch immer geändert, wobei das nicht passieren sollte. Könnte auch dein Problem sein.
Hier mal mein Ticket zum voten

https://issues.jtl-software.de/issues/SHOP-7751

 

[css-umsetzung]

Wofür braucht ein iframe geschweifte Klammern?

Du möchtest vermutlich ein JavaScript snippet einbinden das dir einen Iframe erstellt?
Lass dir ein Portlet machen welches dir eine Codeeingabe erlaubt, das ist nicht so schwierig und ja ich finde auch das dies in der Shop eigenen Portlet Sammlung fehlt.

 

[DRaufeisen]

Wofür braucht ein iframe geschweifte Klammern?

Du möchtest vermutlich ein JavaScript snippet einbinden das dir einen Iframe erstellt?
Lass dir ein Portlet machen welches dir eine Codeeingabe erlaubt, das ist nicht so schwierig und ja ich finde auch das dies in der Shop eigenen Portlet Sammlung fehlt.

Ein bisschen technischer Hintergrund:

Er hat über das Text-Portlet im OPC ein iframe eingefügt, welches eine Drittanbieter-Seite einbindet. In der URL des Iframes ist eine ID enthalten (vielleicht eine Client ID oder so) Diese ist in geschweifte Klammern gefasst {irgendeine_id}.

Unser Shop hat jetzt aber seine Template-Engine Smarty mit einem Output-Filter erweitert. Dabei wird jeder gerenderte Seitencode durch phpQuery geschickt (wenn Plugins aktiv sind die auf den HOOK_SMARTY_OUTPUTFILTER lauschen)
PhpQuery ist dafür verantwortlich, dass Sonderzeichen in href-Attributen im Seitenquelltext escaped werden durch %-Hex-Codes. Das ist üblich und oft auch gewollt.

Die Drittanbieter-Seite geht aber nun davon aus, dass die geschweiften Klammern NICHT escaped wurden und streikt deshalb. Normalerweise müsste die Drittanbieterseite die URL vorher mit der JavaScript-Funktion decodeURI dekodieren.

Grüße,
Danny

 

[css-umsetzung]

HI @DRaufeisen
Ja die ganzen Funktionen usw. sind mir bekannt, aber den content aus dem opc schickt Ihr nicht extra durch smarty und selbst wenn könnte er ja das ganze mit {literal}{/literal} absichern, daher habe ich gesagt, am besten für JavaScripts oder eben eigenen code welcher Art auch immer, ein eigenes Portlet erstellen lassen das auch ohne den Editor und nur mit einem reinem Textfeld arbeitet, so kann man auch sicher sein das der Editor da nicht dazwischenfunkt, der ist für so etwas definitiv nicht geeignet.

Für individuelle Dinge sollte aber unbedingt so ein Textbasierender Editor schon vorhanden sein, es gibt da schöne Dinge wie z.B.: den ACE Editor.
Das währe ein echter Mehrwert für den OPC wenn man den für styles, JS oder zusätzliche reine HTML Eingaben hätte.

Was mich aber so richtig wundert, mein OPC lässt die geschweiften Klammern durch und gibt Sie auch aus, da wird nichts umgeformt bei mir.

 

[Aut_ocean]

Danke für die weiteren Erläuterungen! Inzwischen habe ich mir ein Portlet machen lassen und es ist erfolgreich im Einsatz.