WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => 
Hilfe & Support (deutsch) => Topic started by: evaki on June 23, 2019, 02:57:58 PM
-
BE:
Schreibe ich unter Optionen>Allgemeine Einstellungen>Metatag Titel: z.B. Fix & Foxi, so gibt es beim Abruf von rss.php (News) die Fehlermeldung:
This page contains the following errors:
error on line 7 at column 41: xmlParseEntityRef: no name
Below is a rendering of the page up to the first error.Ersetzt man & z.B. durch and, bzw. entfernt &, erscheint die Fehlermeldung nicht mehr.
Kann das irgend jemand verifizieren?
MfG. Evaki
-
Kann ich bestätigen. Gilt dann auch für rss von Topics und OFA.
Entweder schreibt man dort im Titel "&"
Oder in der rss.php die 2 Vorkommen von WEBSITE_TITLE ersetzen mit
str_replace('&', '&', WEBSITE_TITLE)
Oder die Devs machen da eine Automatik :-)
-
Soll ja utf8 können, oder velwechser ich gerade mal wieder was?
Wär' ja nicht das erste Mal :evil:
Automatik
???
Huch, da war doch was :-D
-
Die Meldung sieht so aus:
XML-Interpretation fehlgeschlagen
XML-Interpretation fehlgeschlagen: Syntaxfehler (Zeile: 7, Zeichen: genau dat &)
Dokument als HTML neu analysieren.
Fehler:
invalid entity reference
Spezifikation:
http://www.w3.org/TR/REC-xml/#NT-EntityRef (http://www.w3.org/TR/REC-xml/#NT-EntityRef)
4: <link>http://meine.domain.de</link>
5: <description><![CDATA[Bumsladen & Team. Alles und Nix aus einer Hand: Entsorgung, Transporte, Shop.]]></description>
6: <language>de</language>
7: <copyright>Copyright 2019, Bumsladen & Team</copyright>
8: <managingEditor>reserve.mail@rsschmidt.tld</managingEditor>
9: <webMaster>reserve.mail@rsschmidt.tld</webMaster>
10: <category>Bumsladen & Team</category>
MfG. Evaki
-
RSS kann zwar utf-8, jedoch werden für einzelne Zeichen wie <>& etc. htmlentities verlangt.
Allerdings sind Entities nicht schön, sondern eher 'bäh..'
Also nimmt man die selbe Lösung wie z.B. beim <description> Tag: Eine CDATA - Klammerung einsetzen. Die RSS-Parser erkennen das als "lass deine Finger da weg und gib es einfach aus.."
<copyright><![CDATA[Copyright 2019, Bumsladen & Team]]></copyright>
<category><![CDATA[Bumsladen & Team]]></category>
sollte das Parserproblem lösen..
Manuela
-
Die Fehlermeldungen von evaki hatte ich nicht, sah nur den Titel der Seite ohne Einträge.
str_replace hatte es gerichtet, aber lieber doch richtiger machen mit ![CDATA[
-
Fehlermeldungen von evaki hatte ich nicht
Kommt aus Opera, aus Chrome vergleichbares. Prinzipiell aus jedem Browser, der XML interpretieren kann. Nur FF ist wieder mal Schrott, da Mozilla die Plugins eigenmächtig deaktiviert, ein Sch... ist das Teil.
Der Fehler (wie auch das Problem mit css2head) fiel nur auf, weil der Anwenderkreis aktuell mit dem Xhtml5/XML-Krams beschäftigt ist. Somit bekomme ich es auch auf's Auge gedrückt. Solange es was bringt - juuuut :-D 8-)
ps. Stricken die DEV das jetzt in RSS(News) und andere Module ein, oder wer macht das?
MfG. Evaki
-
localhost/modules/news/rss.php?page_id=6 // = Status Code: 200 Status: OKWeiß jemand, ob bei RSS die im Template gesetzten header('HTTP/1.0 200 i am just a fake header'); durchgereicht werden müssen? Beim angegebenen Aufruf passiert's jedenfalls nicht - bzw. seh' ich hier nix.
Tut's ja sonst bei allen Seiten. Hab' die entsprechende rfc nicht zur Hand, weshalb ich mal kurz frage.
MfG. Evaki
-
Denkaussetzer, oder was war/ist das? Der Feed is XML und läuft per http. Muß da der header gesetzt sein? Manchmal ist's aber auch...
ps. Mittlerweile zeigt auch mein FF den Parsererror an, aber ohne Fehlerbeschreibung - mehr als dürftig. Den vorhandenen Fehler bzw. das Ergebnis seh' ich selbst - ::kopffaß::
MfG. Evaki
-
Noch was vergessen.
4: <link>http://meine.domain.de</link>
Wie verhält sich das Teil bei einer IDN-Domain. Gibt's da Probleme?
Ist schon klar, utf8 jeht - aber bevor noch 'ne Überraschung kommt.
Habe im Moment keinen Zugang zu einer.
Kann wer gucken, machen...?
MfG. Evaki
-
Muß da der header gesetzt sein?
Bitte nicht HTTP - HTML - XML verkuddelmuddeln! ;)
HyperTextTransferProtokoll ist ein Transportprotokoll
HyperTextMarkupLanguage und
eXtensibleMarkupLanguage sind Auszeichnungssprach en.
Kurz gesagt: Content, der in HTML oder XML formatiert ist, kann über das HTTP übertragen werden.
Das HTTP Protokoll ist (wie andere Protokolle z.B. FTP auch) so aufgebaut, dass ein Requester (Browser, Reader, etc.) eine Anfrage an den Server sendet und als Antwort erst einmal einen Status der Verbindung erwartet. Wenn alles gut ging, ist das '200 OK'. Es könnte aber auch eine 404 oder gar 500 zurück kommen.
Da RSS-Feeds nix anderes als HTTP-Requests sind die auch einen HTTP-Response erwarten, erwartet ein strikt gecodeter Reader auch die 200 als Antwort.
Also header('HTTP/1.0 200 OK');
"Ich sende aber praktisch nie einen Status-Header mit!" Ist so nicht ganz richtig. ;-) Denn, falls der Status-Header fehlt, hängen die meisten Server diesen selbstständig vorne dran.
Allerdings sollte man auf solche Jokes wie header('HTTP/1.0 200 i am just a fake header'); verzichten und dann schon den 'richtigen' Header header('HTTP/1.0 200 OK'); einsetzen.
Wie verhält sich das Teil bei einer IDN-Domain. Gibt's da Probleme?
Nein, denn es sind nur die 'Sonderzeichen' (Steuerzeichen) die Probleme bei der Ausgabe machen.
-
HTTP - HTML - XML verkuddelmuddeln!
Keinesfalls, da hier mit Tools gearbeitet wird. die dies alles parallel erfassen, inklusive ein header('HTTP/1.0 200 i am just a fake header'); , der z.B. mit headers_list(); über'n Browser nicht ausgegeben wird - da streikt auch der Parser bei XML/RSS - , aber hier genutzt werden kann, um das "Durchreichen" der im Template gesetzten Header überprüfen zu können. Und warum? Weil man sehen wollte, ob z.B. CSP bzw. die im Template gesetzten Header durchgereicht werden.
Hier lautete/lauerte die Frage, ob bei RSS/XML bzw. in WB an dieser Stelle überhaupt die Notwendigkeit für derartige "Sicherheits-Header" besteht (rfc). Da bin ich im Moment nämlich überfragt (Wissenslücke). Und über Sicherheitsprobleme an dieser Stelle habe ich bisher noch nichts gelesen, was ja nix heißen muß.
MfG. Evaki
-
Ganz so doof scheint meine/unsere Fragerei diesbezüglich doch nicht zu sein.
Ein im BE nachträglich in <description> </description>untergebrachtes <script> blabla <script>, also
<description><script> blabla <script></description> funktioniert jedenfalls, und ist konform.
Der ganze Vorgang ist aber wohl 'ne rein theoretische Konstruktion, und unterstellt WB-Anwendern böse Absichten. Zeigt aber was möglich ist. Worüber die sich hier allns Gedanken machen... :?
ps. Das kommt gerade noch herein. Ist 'ne verkürzte Wiedergabe: Ein CSP-Header neben anderen in rss.php könnte evtl. helfen. Über die möglichen Regeln hat sich noch niemand ausgelassen.
MfG. Evaki
-
Kann ich für die letzte Revision nicht bestätigen. Verstehe auch nicht ganz was BE mit RSS zu tun hat.
Jedenfalls solche <script>bla Sachen im Description-Teil werden im BE komplett entfernt, sowohl in Optionen als auch in den Seiteneinstellungen .
Aber ich verstehe dich sicher falsch.
-
Hätt' ich genauer wiedergeben sollen.
Nun gut, dann für die Bösen :evil:
Im BE News Kurz=
<p>"Pärchen beim Vögeln in der Telefonzelle erwischt"</p>
<script>
document.write(markup);
</script>
<p>Richter lehnt Bestrafung ab.</p>Der RSS-Aufruf bekommt das Script.
Aber auch klar: Darauf muß man erstmal kommen...
Und: Ich bin nicht schuld, hab' nix damit zu tun, das war'n die anderen. :-D
MfG. Evaki
-
Da die RSS-Aufgabe hierbei XML-konform ist, gibt's da auch nix einfach mal per Automatik was wegzuradieren. Wenn wer etwas dort nicht zu sehen wünscht, trotz der XML-Konformität, kann <script> wohl in NEWS brachial unterbinden. Ob da nicht wie angedacht eher CSP angebracht ist, kann man überdenken.
Das sollen die DEV entscheiden, ob das relevant ist. Nicht jeder Furz braucht CSP, und - Eigenverantwortung ist auch hier gefragt. Allein die theoretische Möglichkeit kann nicht immer bei sowas herhalten.
Auf den ersten Blick ist das ja schon gemein, da so'n Script ansonsten nirgens zu entdecken ist. Sowas sieht auch keine Sicherheits-Suite, ist ja alles konform :-D
MfG. Evaki
ps. Ich hab' überhaupt nix gemacht, die anderen...
-
In meinem RSS ist kein <script> zu sehen. Aber auf der Newsseite.
Das kommt wohl davon, dass wir einigen hier erlauben wollten, im CK im Quelltext, einem Div auch eigene Sachen wie id, class oder sonstwas mitzugeben. Da wurde wohl gleich alles erlaubt. :)
edit: allerdings sehe ich in der wb_ckconfig.js
config.disallowedCo ntent = 'script; *[on*]';
-
Nix zu sehen?
Bei mir überal, diesmal mit FF und XML-Plugin:
Aufruf: modules/news/rss.php?page_id=6
<generator>
WebsiteBaker Content Management System
</generator>
<item>
- 5 children, 5 leafs
<title>
<![CDATA[Abendzeitung:"Pärchen beim Vögeln in der Telefonzelle erwischt"]]>
</title>
<description>
<![CDATA[<p>"Pärchen beim Vögeln in der Telefonzelle erwischt"</p>
<script>
document.write(markup);
</script>
<p>Richter lehnt Bestrafung ab.</p>
]]>
</description>
<link>
http://localhost/posts/abendzeitung-paerchen-beim-voegeln-in-der-telefonzelle-erwischt-1.php
</link>
<pubDate>
ps. Anscheinend verhindert <![CDATA nicht die Ausführung von <script>, wenn ich das ganze Geraffel hier richtig nachvollzogen habe.
Kannst ja mal statt document.write(markup); eine Referenz zu irgendeiner Homepage testen - hab' ich noch nicht gemacht - z.B. 'ne Umleitung, sollte damit angeblich funktionieren.
Bei mir läuft alles unter der aktuellen WB-Version, also keine Zeitreise in die Zukunft.
MfG. Evaki
-
Sorry, ich hatte mit F12 geschaut. Im Quelltext sehe ich es wie du.
Die Erklärung scheint hier zu stehen:
https://ckeditor.com/docs/ckeditor4/latest/guide/dev_disallowed_content.html#how-to-allow-everything-except
Wenn alles erlaubt wird, wirken die Ausnahmen nicht. Zitat:
"A popular requirement is to allow all HTML features except a few specific ones. In this case setting CKEDITOR.config.all owedContent to true is not a solution, because this completely disables the Advanced Content Filter, so CKEDITOR.config.dis allowedContent will not work either."
Eine Lösung steht da auch. Mal sehen was Dietmar sagt.
-
CDATA sorgt nur dafür, dass der Inhalt der Klammer garantiert unverändert (also nicht durch den Reader geparst) übertragen wird. Was der Empfänger dann mit <script> oder <style> Tags anfängt... ist dessen Problem (oder auch nicht).
-
So, nachdem mir nun zwar nicht der Kopf schwirrt, aber ich mal 'nen Blick über'n Tellerrand riskieren wollte -
Goggel: rss javascript xss
Das Thema scheint bekannt zu sein.
https://www.cgisecurity.com/papers/HackingFeeds.pdf
https://security.stackexchange.com/questions/184772/avoid-malicious-javascript-in-rss-feeds
Schon mal gut zu wissen: "wir sind nicht allein" :-D
-
Was der Empfänger dann mit <script> oder <style> Tags anfängt... ist dessen Problem (oder auch nicht).
Ich bin dann wohl der erste, der dann wieder - nicht unbedingt zu Unrecht - schreit: "Was soll ich mit 'nem kastrierten NEWS bzw. RSS? Warum werden hier RSS/XML-Eigenschaften eingeschränkt?" Standards sollen/wollen genutzt werden können. Schon wieder entscheidet irgendwer, was für die Anwender gut ist/sein soll. :-D
Im Topic ging's ja ursprünglich nur um das & hier, was ein Bug war/ist.
Der Rattenschwanz hinterher ergab sich nur durch die Exerimentiererei in meinem Anwenderkreis, und es ergaben sich dadurch halt ein paar interessante Fragen und Einsichten.
Ob mit diesen auch Sicherheitsprobleme verbunden sind, gilt es natürlich zu beachten.
Wer Mißbrauch betreiben will, kann das an beliebiger Stelle und mit beliebigem CMS. Einränkungen wg. Sicherheitsapekten, sollten die Nutzbarkeit natürlich nicht einschränken. Andererseits hat bisher noch niemand die Möglichkeit des <script> - Elements vermißt bzw. genutzt...........
MfG. Evaki
-
Nochmal über'n Tellerrand geschaut und wieder schlauer, bzw. erkannt was ich verpennt habe.
Für 'nen Halbwissenden ist's aber auch nicht so ganz leicht den Kram unter allen Aspekten zu sehen.
In XML gehört <script> nicht zum Standard, was ich im häufigen Umgang mit XML "eigentlich" hätte wissen müssen. Mit XSLT ist es wiederum möglich (transformieren in Xhtml).
Der Aufruf von /modules/news/rss.php?page_id=6 liefert die XML-Rohdaten, weshalb das über NEWS eingeschleuste <script> dort nix zu suchen hat.
Bedeutet nach meinem aktuellen Kennnisstand, daß man in NEWS das <script> ausschließen muß, um den Eingang in's (RSS)XML zu verhindern.
Nun hoffe ich, daß ich's kapiert habe.
Vielleicht kann das von DEV ja bestätigt werden.
MfG. Evaki
-
Vielleicht kann das von DEV ja bestätigt werden.DEVinitiv bestätige ich dir, dass <script> im CK nichts zu suchen hat und damit auch in News und RSS nicht.
Wird in der nächsten Version gefixt sein. Lösung hatte ich verlinkt.
Wenn der DEV nicht doch noch alles anders macht. Man weiß es ja nie. :-)
-
dass <script> im CK nichts zu suchen hat
In NEWS ok, aber im CK nicht??? JS darf doch, soweit ich weiß, im Gegensatz zu CSS, an beliebiger Stelle im html-Code stehen.
Oder geht mein Hirn gerade gegen Null? Bin nämlich so langsam alle. Für heute war's genug der Aufregung. :-D
MfG. Evaki
<offtopic>
Wo steckt eigentlich jacobi22?
</offtopic>
-
In NEWS ok, aber im CK nicht?
Der CK ist der eingestellte Standardeditor. News und Wysiwyg nutzen den.
Ein normaler User setzt kein Script in den Text. Sonst könnte man wieder alles erlauben.
Müsste man wissen wie wichtig es wäre, dass auch script oder onchange möglich ist.
-
Ich frag jetzt mal hier, da mir jacobi22 aus irgendwelchen Gründen nicht mehr antwortet... (ist der im Urlaub?). Vor einigen Wochen hatte ich ja schon das Problem, dass ich eine rss.php aus einem OFA-Modul generieren wollte. Siehe hier: https://forum.WebsiteBaker.org/index.php/topic,31424.msg220484.html#new Ich brauche dazu aber in der <description> ... </description> mehr als nur EIN Feld aus OFA! Das Bild (über Bild-Upload) hochgeladen konnte ich ja inzwischen integrieren - nicht aber das Bildcopyright (ist ein eigenes Feld). Außerdem möchte ich bei <pubDate>..</pubDate> nicht das Datum der Veröffentlichung haben, sondern ein Datums-Feld aus OFA (da ich dort Meldungen der letzten 10 Jahre manuell importieren werde - das Veröffentlichungsda tum ist somit immer 2019, aber das eigentliche Datum liegt bis zu 10 Jahre zurück!). Oder <pubDate> komplett ausschalten, dafür das Feld aber in die Description mit einbauen.
Momentan enthält die Schleife also:
<description>[IMAGE] [FIELD_2]</description>
Ich brauche aber sowas wie:
<description>
[IMAGE]
<div class="bildunterschrift">[FIELD_3]</div>
<li>[FIELD_2] ([FIELD_1])</li>
</description>
Feld 1 ist Datum - Feld 3 ist das Bildcopyright.
Wie bekomme ich das hin? Der Kunde hatte bei seiner vorigen (statischen) Website bereits einmal eine Abmahnung wegen fehlendem Bild-Copyright im RSS-Feed und ist da sehr empfindlich! Das muss also vor Freischaltung gelöst sein!
LG,
Astrid
-
Dein Problem passt hier nicht rein. Bitte verwende deinen eigenen Thread.
Wenn du dich dort immer direkt an Uwe wendest, wird vielleicht niemand anderes antworten.
-
Der CK ist der eingestellte Standardeditor. News und Wysiwyg nutzen den.
Ein normaler User setzt kein Script in den Text. Sonst könnte man wieder alles erlauben.
Der ist kein normaler User, der DHTML nutzt?
Also verbietet man? Kann man sich das mit dem Verbieten nicht mal langsam abgewöhnen?
CK nicht nach seinen Wünschen gestalten zu können ist mehr als schräg.
Inhalte nicht mit DHTML ausstatten zu können auch!
NEWS muß nicht zwingend mit dem Standard-Editor zwangsverheiratet sein.
Erst dadurch entsteht das Problem!
MfG. Evaki
-
Müsste man wissen wie wichtig es wäre, dass auch script oder onchange möglich ist.
Wenn du Angebote ausschlägst, die passende Mischung zwischen Sicherheit und Freiheit zu finden, kann man nicht helfen.
Ich denke ich habe mehrfach zum Ausdruck gebracht, dass man sich das Optimale gern erarbeiten kann.
Von dir kommen aber oft nur Vorwürfe. An dem Punkt ist für mich dann nichts mehr zu machen.
Wende dich bitte direkt an Dietmar.
-
Feststellungen und etwas infrage zu stellen hat nichts mit Vorwürfen zu tun, schon gar nicht welche, die sich an eine Person richten. - Wie komme ich dazu?
Meine Aussagen sind Beiträge zur Sachlage, sonst nix. Und wohlmeinend!
Bei Entscheidungen zu "zwischen Sicherheit und Freiheit" kommt mir nicht DHTML in den Sinn.
Da CKEdit nicht nur in WB genutzt wird, kann man sich mal hierzu andere CMS anschauen.
Da geht's.
Ich und andere wollen die Freihet haben DHTML und alles andere was per Norm existiert zu nutzen.
Es ist also keine Frage der Sicherheit. Hier wird etwas verwechselt.
MfG. Evaki
ps. Entdecke ich erst jetzt
>>"Wende dich bitte direkt an Dietmar."
Ich betrachte Beiträge, insbesondere die von Dir als Hilfe; Anregungen und Vorschläge, die ich nicht missen mag.
Ich ging außerdem bisher davon aus, daß DEV hier regelmäßig reinschauen, und den unterschiedlichen Gedanken und Vorschlägen vielleicht auch folgen.
Somit habe ich die Beiträge von Dir nie als Grundlage für einen Disput betrachtet. Im Gegenteil, wegen teils unterschiedlicher Auffassungen gab's es ja erst das "Reinknien" und Nachhaken.
-
Hatte geschrieben, dass man nicht einfach alles erlaubt, sondern rausfinden muss was erlaubt sein sollte.
Das muss man nämlich alles extra zulassen/aufzählen. Sollte eigentlich durch den CK Link gestern veranschaulicht werden.
-
Dem Link bin ich gefolgt.
Da stiime ich Dir gerne zu. Da bleibt's dann jedem selbst überlassen was und wie er CK nutzen will.
Doof ist halt - erst jetzt fällt's mir deutlich auf, daß Du immer CK genannt hast, ich aber immer NEWS, wenn's um die Verhinderung von <script> ging - Die Zwangsverheiratung, ohne diese Koppelung gäbe es das Dilemma nicht.
Hab' nicht reingeguckt, und frag mal janz doof, hilft nicht'n Filter in view von news?
MfG. Evaki
-
Ich ging außerdem bisher davon aus, daß DEV hier regelmäßig reinschauen
Kannst du.
Ich versuche Probleme zu verstehen und zu vermitteln. Je mehr das also versuchen, desto näher kommt man vielleicht dem was sinnvoll für alle ist.
Die Überlegung, etwas modulbasiert zu machen, gab es auch. Hier helfen dann nur deine Argumente weiter. Das ist halt immer das Dilemma bei der Kommunikation. Versteht der andere das was gemeint war, oder kann man es auch anders verstehen.
Wir werden sehen.
-
So, alle nochmal zusammengetrommelt und die Sachlage besprochen.
Ergebnis:
Der Vorgang stellt anscheinend kein Sicherheitproblem dar.
Egal ob in NEWS/CKE so ein Script unter "News Kurz" eingetragen wird - es wäre erlaubt!
Es verursacht im ausgegebenen RSS/XML "nur" einen Fehler, das XML ist nicht mehr valide.
Das ist alles, sonst nix :roll: (ja gut, haben mal wieder dazugelernt :-D )
Die Ausgabe kann im RSS.php anscheinend gefiltert werden (mit Zeigefinger auf die Programmierer :-D ) ,der Inhalt inkl. <script> steht in der db unter content_short, und wird von rss.php über $description = stripslashes($item["content_short"]); ausgegeben, wenn ich das jetzt richtig verstanden habe. Kann ja wer 'nen Filter basteln, wenn dat allens so richtich is.
MfG. Evaki
Nachtrag.: FRAGE Wär's statt nun 'nen Sperrfilter für alles Unerlaubte zu stricken, nicht sinnvoll einen Durchlaßfilter/PASS für die vorgegebenen Elemente einzurichten?
-
Ich gebe mir mal selbst die Antwort.
<item>
<title><![CDATA[<?php echo stripslashes($item["title"]); ?>]]></title>
<?php
$muell = array("<script>", "</script>", "<noscript>", "</noscript>");
$description = str_replace($muell, "", $description); ?>
<description><![CDATA[<?php echo $description; ?>]]></description>
Zwar ist es immer noch möglich einen für RSS/XML nicht validen Code in NEWS einzubetten, aber <script> wird im RSS/XML entfernt, als eine reine Vorsichtsmaßnahme. Die Strings - hier html5 - lassen sich natürlich auch html-abwärtskompatibel und um sonstigen Kram erweitern.
Sinnvoll ist auch in die RSS-Doc's reinzuschauen, damit erst garkeine nonvalide Codes Eingang finden. Wie man sehen konnte, ist das ja machbar/möglich.
Das war's wohl zu beiden Anliegen, oder ist noch was offen?
Eigentlich ganz schön viele Wege, Wirrungen und Irrungen für so'n Spaß - muß aber anscheinend sein, wenn man keine Ahnung hat.
MfG. Evaki
-
$muell = array("<script>", "</script>", "<noscript>", "</noscript>");
$description = str_replace($muell, "", $description); ?>
Der Code funktioniert, um die meisten neueren Tags als solche zu entfernen, nicht jedoch den enthaltenen JS-Code.
Allerdings kann solch ein Tag noch zusätzliche Parameter haben, z.B: <script type="javascript"> und dann klappt str_replace() nicht mehr.
Folgender Code entfernt sowohl <script> als auch <noscript> Tags, unabhängig von eventuellen Parametern oder überflüssiger Leerzeichen in den Tags und dazu gleich auch noch den Inhalt innerhalb der Tags.
$description = \preg_replace('/(.*?)(<(?:no)?script[^>]*>[^<]*<\/(?:no)?script>)(.*?)/is', '$1$3', $description);
Die 2. Lösung entfernt "<script>JS-Code</script>" komplett und bei "<noscript>HTML-Inhalt</noscript>", lässt sie den HTML-Inhalt stehen. [rot wird gelöscht, blau bleibt stehen]
$description = \preg_replace('/(.*?)(?:(?:<script[^>]*>[^<]*(\s?)<\/script>)|(?:<noscript[^>]*>([^<]*)<\/noscript>))(.*?)/is', '$1$2$3', $description);
-
Danke, danke, hilft weiter!
So kann jeder, der jetzt schon den Patch möchte, schon mal loslegen.
Die von mir vorgestellte Lösung ist eine rein pragmatische, mit dem Hintergedanken, daß wenn <script> fehlt, auch die Ausführung damit entfällt. Wenn dann Code - mit <script> "unsichtbar" - und anderes zu sehen sein sollte, weiß man, das gehört nicht dahin - so wie auch html in noscript :?
Außerdem war ich zu faul mich wieder mal mit preg_replace rumzuschlagen
- wenn ich's (noch) vermeiden kann :-D
Tja, und manchmal muß man vorlegen, damit etwas zurück kommt.
MfG. Evaki
-
Will man den erwünschten Effekt nicht nur bei html5 erreichen,
dann statt
$muell = array("<script>", "</script>", "<noscript>", "</noscript>");
so
$muell = array("<script", "</script>", "<noscript>", "</noscript>");
Ausführung auch nach unten hin kompatibel verhindert.
MfG. Evaki