Ich habe eine Javascript-Anwendung, die von einem CloudFront-Endpunkt an den Browser ausgeliefert wird. Alle statischen Dateien der Anwendung werden in einem S3-Bucket gehostet. Dazu gehören eine ganze Reihe von Javascript- und CSS-Dateien sowie einige Schriftdateien.
Das HTML, das die gesamte Anwendung lädt, wird von einem Server generiert und bereitgestellt. Nennen wir diesen Server „https://my.domain.com“.
Wie erwähnt, ist dies nur die HTML-Datei.AlleStatischer Inhalt wird dann vom Cloudfront-Endpunkt heruntergeladen, der auf einen Bucket als Ursprung verweist. Nennen wir diese xxxx.cloudfront.net und den Bucket my-bucket.
Soweit ich es verstehe, ist praktisch jede Anfrage von diesem generierten HTML an den Cloudfront-Endpunkt eine CORS-Anfrage, da der Ursprung des HTML my.domain.com ist und alle angeforderten Dateien offensichtlich nicht auf dieser Domäne gehostet werden.
Also habe ich natürlich angefangen, den ganzen CORS-Kram einzurichten. Zunächst einmal ist der Bucket komplett öffentlich und hat die folgende CORS-Richtlinie:
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET"
],
"AllowedOrigins": [
"*",
],
"ExposeHeaders": [],
"MaxAgeSeconds": 3000
}
]
Und das scheint für alles zu funktionieren ...außerdie Schriftdateien! Ich sollte wahrscheinlich die Ordnerstruktur des Buckets erwähnen. Er hat drei Ordner: Produktion, Entwicklung und Allgemein. Der Inhalt dieser Ordner sollte ziemlich selbsterklärend sein. Allgemein enthält die Schriftarten sowie einige JavaScript-Bibliotheken von Drittanbietern. Produktion und Entwicklung enthalten das JS und CSS für ihre jeweiligen Umgebungen.
In jedem Fall,alleswird geladen, mit Ausnahme der Schriftdateien, für die ich die folgende Fehlermeldung erhalte:
Access to font at 'https://xxxx.cloudfront.net/common/fonts/outline/budicon-classic.ttf?jdete2' from origin 'https://my.domain.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Es kam mir äußerst merkwürdig vor, dassnurdie Schriftdateien hätten dieses Problem. Andere Dateien im gemeinsamen Ordner scheinen problemlos geladen zu werden, und wenn ich einfach einfügehttps://xxxx.cloudfront.net/common/fonts/outline/budicon-classic.ttf?jdete2in meinen Browser, esWerke.
Der einzige Unterschied scheint zu sein, dass diese Dateien nicht aus dem HTML, sondern aus dem CSS über das @font-face-Ding geladen werden. Wenn ich mir die Anfragen anschaue, die der Browser beim Laden der Anwendung generiert, kann ich deutlich erkennen, dass beispielsweise der Origin-Header gesetzt ist, was bei der Anforderung von JS- oder CSS-Dateien nicht der Fall war. Set-Fetch-Mode ist auf „cors“ eingestellt, während es für die anderen Dateien auf „no-cors“ eingestellt war.
Auf jeden Fall habe ich versucht, das Problem auf der Cloudfront-Seite zu beheben. Zuerst habe ich der Ursprungskonfiguration den Header „Access-Control-Allow-Origin: *“ hinzugefügt. Dann habe ich eine Verhaltenskonfiguration für den Ursprung hinzugefügt, um GET, HEAD, OPTIONS für das Pfadmuster * zuzulassen.
Und jetzt... also, jetzt habe ich immer noch dasselbe Problem und bin völlig ideenlos. Ich frage mich allerdings, warum die von @font-face erstellte Anfrage so anders aufgebaut ist als die Anfragen für JavaScript- und CSS-Ressourcen, aber vor allem, was um Himmels Willen ich tun kann, um diese verdammten Schriftarten zu laden?
Antwort1
Ok, das war ärgerlich, aber ich denke, es war logisch.
Die Korrekturen, die ich oben gepostet habearbeite, aber Konfigurationsänderungen machen den Cloudfront-Cache nicht ungültig. Und da CORS-Fehler durch denBrowser, Cloudfront hat diese Antwort mitsamt den Headern und allem zwischengespeichert, da es nichts Falsches daran erkennen konnte.
Lange Rede, kurzer Sinn: Der Cloudfront-Cache wurde nach Konfigurationsänderungen ungültig, jetzt funktioniert er. ARGH!