Festlegen von Access-Control-Allow-Origin auf Cloudfront Cached-Objekt

Question

Schriftarten, die über Cloudfront bereitgestellt werden, sind in Firefox aufgrund des Problems "bad URI or cross-site access not allowed" beschädigt. Um dies zu beheben, muss der Header "Access-Control-Allow-Origin" auf einen Platzhalter oder die Quelldomäne gesetzt werden.

Das Problem, das ich habe, ist, dass Cloudfront Header von der Herkunft nicht akzeptiert scheint.

Zum Beispiel ist die folgende die Liste der Header ich bekomme, wenn ich meinen Server für die Schriftart ping:

curl -I -s "https://mysite.com/wp-content/themes/my-theme/includes/fonts/ProximaNova-Reg-webfont.ttf" 
HTTP/1.1 200 OK 
Server: nginx 
Date: Wed, 29 Jan 2014 16:03:03 GMT 
Content-Type: application/x-font-ttf 
Content-Length: 44992 
Last-Modified: Tue, 28 Jan 2014 22:21:41 GMT 
Connection: keep-alive 
ETag: "52e82d75-afc0" 
Expires: Thu, 29 Jan 2015 16:03:03 GMT 
Cache-Control: max-age=31536000 
Access-Control-Allow-Origin: https://mysite.com 
Access-Control-Allow-Methods: GET 
Access-Control-Max-Age: 3600 
Accept-Ranges: bytes 

Alles sieht mit dieser Antwort gut; jedoch, wenn ich ping Cloudfront für die gleiche Ressource, die ich erhalten:

curl -I -s "https://ds6dj5kp03o39.cloudfront.net/wp-content/themes/my-theme/includes/fonts/ProximaNova-Reg-webfont.ttf" 
HTTP/1.1 200 OK 
Content-Type: text/plain 
Content-Length: 44992 
Connection: keep-alive 
Date: Wed, 29 Jan 2014 16:22:30 GMT 
Server: Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o 
Last-Modified: Wed, 22 Jan 2014 02:44:45 GMT 
ETag: "5d633-afc0-4f0861b87a140" 
Accept-Ranges: bytes 
Cache-Control: max-age=3600 
Expires: Wed, 29 Jan 2014 17:22:30 GMT 
X-Cache: Miss from cloudfront 
Via: 1.1 850e11212c3f83bfb138469e9b3b7718.cloudfront.net (CloudFront) 
X-Amz-Cf-Id: M4qkj9FwjdAUW91U4WeZzxEI0m7vOmiQvryS55WwoeU5Ks11IC71ig== 

Es scheint, dass alle der Herkunft Header vollständig ignoriert werden. Meine Frage ist, Wie bekomme ich Cloudfront, um meine Asset-Header zu akzeptieren, vor allem die kritische "Access-Control-Allow-Origin" -Header?

Danke für die Hilfe!

Answer 1

Was Sie getan haben, ist richtig, aber CloudFront speichert die Ergebnisse zwischen, daher erhalten Sie die alte zwischengespeicherte Version. Sie können dies in dem Header sehen: von Ihrer Website:

Last-Modified: Di 28. Januar 2014 22.21.41 GMT

von Cloudfront:

Last-Modified: Wed, 22 Jan 2014 02:44:45 GMT

Jetzt, wie man es wieder funktioniert:

a) Warten Sie, bis das Objekt abläuft, und fordern Sie es dann erneut an. CloudFront wird es dann aktualisieren.

b) Invalidieren Sie die Objekte mit Ihrer Amazon Konsole> cloudfront> distribution> Invalidations. Siehe http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html für Details zur Verwendung dieser

c) Ändern Sie den Namen oder starten Sie die Verwendung eines versionierten Namens für die Datei, z. ProximaNova-Reg-webfont_2.ttf

Answer 2

Wenn Sie zu einem späteren Zeitpunkt zu diesem Thema kommen und dieses Problem mit einem benutzerdefinierten Ursprung haben, der den Access-Control-Allow-Origin-Header bereits korrekt bedient, sind hier zwei Dinge, die ich überprüft habe/versucht:

1. überprüfen sie, ob Ihre nginx oder apache-Konfiguration hat in Anführungszeichen das *, wenn es hat, versuchen, sie zu entfernen.
2. Stellen Sie sicher, dass Sie die richtigen Inhaltstypen für Woff- und TTF-Dateien übergeben.Das war die schnellste Verbindung, die ich zu dem Thema gefunden - https://github.com/fontello/fontello/wiki/How-to-setup-server-to-serve-fonts

Apache

richtigen Mime-Typen für Font-Dateien zu setzen, fügen Sie diese Zeilen zu config:

AddType application/vnd.ms-fontobject .eot 
AddType application/x-font-ttf   .ttf 
AddType application/font-woff   .woff 

Wenn Sie die Konfiguration nicht bearbeiten können, erstellen Sie die Datei .htaccess im Ordner mit Ihrem Projekt und fügen Sie dort Zeilen hinzu.

Für CORS-Header fügen Sie den Code unten:

<FilesMatch ".(eot|ttf|otf|woff)"> 
    Header set Access-Control-Allow-Origin "*" 
</FilesMatch> 

Sie service apache2 restart ausführen müssen, wenn Sie diese Änderungen vornehmen, und wenn Sie den Fehler erhalten Invalid command 'Header' dann bedeutet es, Sie nicht das mod_header Modul in Apache aktiviert haben die Sie mit a2enmod headers

nginx tun können

standardmäßig nginx hat keine Standard-Mime-Typen für Schriftarten und WRO ng Mimy Typ für .eot Dateien. Gehe zum Ordner mit Configs und finde wo mime Typen entweiht sind. Normalerweise ist das in der mimes.conf-Datei.

Suche .eot und Zeichenfolge mit ihm. Strings hinzufügen unten:

application/vnd.ms-fontobject eot; 
application/x-font-ttf   ttf; 
application/font-woff   woff; 

Für CORS-Header, um so etwas zu Ihrem vhost Config hinzufügen

location ~* \.(eot|ttf|woff)$ { 
    add_header Access-Control-Allow-Origin *; 
} 

Answer 3

Es ist eine explizite Konfiguration für Ihre Eimer CORS-Header dynamisch zu bewerten.

1. Siehe AWS CORS docs
2. Auch ein detailed explanation ihrer Verwendung

Versuch CORS-Header oder auf andere Weise für CF oder S3 eingestellt wird verworfen, weil es ihr Caching-Modell brechen.

Answer 4

In der Standardkonfiguration überprüft CloudFront keine Header oder speichert deren Werte zwischen. Ein wahrscheinlicher Schuldiger für Sie ist, dass Ihre Ressource zuerst ohne einen "Origin" -Header angefordert wird und daher S3 keine CORS-Header als Antwort anbietet. Die Antwort wird zwischengespeichert, und wenn Sie später eine quellenübergreifende Anforderung stellen, wird die zwischengespeicherte Antwort ohne sie ausgeführt.

Sie können CloudFront so konfigurieren, dass der Origin-Header an S3 weitergeleitet wird und unterschiedliche Antworten für verschiedene Headerwerte zwischengespeichert werden, wodurch CloudFront bei Bedarf die CORS-Header zwischenspeichert. Siehe http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors.