Problem mit relativem Pfad verursacht CORS-Fehler auf Discourse-Seiten

Der folgende Code in lib/highlight_js.rb funktioniert auf einigen Domains, aber nicht auf anderen:

def self.path
    "/highlight-js/#{Discourse.current_hostname}/#{version SiteSetting.highlighted_languages}.js"
end

Ich habe zwei Discourse-Sites. Dieser Code funktioniert auf der Domain www.abc.com, aber nicht auf efg.com. In der Browserkonsole sehe ich folgende Fehlermeldung:

formatter.js:383 Uncaught (in promise) TypeError: Failed to resolve module specifier '/highlight-js/efg.com/9797975efac87d28baa695ae13ca72ccaf5120f5.js'. Die Basis-URL ist about:blank, da import() aus einem CORS-übergreifenden Skript aufgerufen wird.

Nachdem self.path in highlight_js.rb wie folgt geändert wurde:

def self.path
    "https://#{Discourse.current_hostname}/highlight-js/#{Discourse.current_hostname}/#{version SiteSetting.highlighted_languages}.js"
end

wurde das Problem behoben.

Es scheint, dass die Verwendung eines relativen Pfads wie
import('/highlight-js/efg.com/9797975efac87d28baa695ae13ca72ccaf5120f5.js')
ein CORS-Problem verursacht, während die Verwendung einer absoluten URL,
import('https://efg.com/highlight-js/efg.com/9797975efac87d28baa695ae13ca72ccaf5120f5.js') ,
einwandfrei funktioniert.

1 „Gefällt mir“

Seltsam, dass es mit abc.com funktioniert, aber nicht mit efg.com, da die 2 verschiedenen Routen völlig unterschiedlich sind :thinking:

Ich meine, es funktioniert mit www.abc.com, aber nicht mit efg.com. Ich bin mir nicht sicher, warum, aber es passiert in meinen Fällen.

1 „Gefällt mir“

Verwenden Sie auf einer dieser Websites ein CDN? Ich habe festgestellt, dass die Codehervorhebung auf meiner Website nicht mehr funktioniert, und ich glaube, das liegt daran:

In meinem Fall gibt mein CDN keinen Access-Control-Allow-Origin-Header für die highlightjs-Datei zurück. Ich bemerke, dass Metas CDN diesen Header enthält, daher frage ich mich, was anders ist.

$ curl --silent -I https://d3bpeqsaub0i6y.cloudfront.net/highlight-js/meta.discourse.org/9797975efac87d28baa695ae13ca72ccaf5120f5.js | grep -i access-control
access-control-allow-origin: *
access-control-allow-methods: GET, HEAD, OPTIONS

Diese Header werden jedoch nicht vom Ursprungsserver bereitgestellt:

$ curl --silent -I https://meta.discourse.org/highlight-js/meta.discourse.org/9797975efac87d28baa695ae13ca72ccaf5120f5.js | grep -i access-control

Soweit ich das beurteilen kann, ist Discourse dafür gedacht, Access-Control-Header zu den highlightjs-Dateien hinzuzufügen:

Allerdings werden diese Header nur angewendet, wenn die Anfrage eine „CDN-Anfrage“ ist:

Dies funktioniert nur, wenn Discourse mit einem separaten Hostnamen für „CDN-Anfragen“ konfiguriert ist.

1 „Gefällt mir“

Es gibt eine Einstellung, cdn_origin_hostname, die vielleicht auf den normalen Discourse-Hostnamen gesetzt werden könnte:

Ich denke, dies würde dazu führen, dass die Prüfung is_cdn_request erfolgreich ist, aber ich weiß nicht, ob dies negative Nebenwirkungen hätte.

Ja, ich verwende ein CDN für efg.com, aber wenn ich auf die JS-Datei zugreife, gibt sie mir ein korrektes Access-Control-Allow-Origin zurück, was mich ziemlich verwirrt.

Als Nachtrag: Ich habe cdn_origin_hostname auf den normalen Domainnamen meiner Discourse-Instanz gesetzt, den CDN-Cache geleert und jetzt funktioniert highlightjs wieder. Ich habe keine Nebenwirkungen bemerkt

Ich habe dieses Problem auch. Gibt es Neuigkeiten?