Définition du contrôle d'accès-autorisation-origine sur Cloudfront

J'ai des problèmes pour servir des actifs statiques à Firefox à l'aide d'AWS Cloudfront.

Chrome fonctionne parfaitement, mais Firefox renvoie une erreur CORS.

Si j'exécute curl, j'obtiens:

HTTP/1.1 200 OK
Content-Type: application/x-font-opentype
Content-Length: 39420
Connection: keep-alive
Date: Mon, 11 Aug 2014 21:53:50 GMT
Cache-Control: public, max-age=31557600
Expires: Sun, 09 Aug 2015 01:28:02 GMT
Last-Modified: Fri, 08 Aug 2014 19:28:05 GMT
ETag: "9df744bdf9372cf4cff87bb3e2d68fc8"
Accept-Ranges: bytes
Server: AmazonS3
Age: 2743
X-Cache: Hit from cloudfront
Via: 1.1 c445b20dfbf3128d810e975e5d84e2cd.cloudfront.net (CloudFront)
X-Amz-Cf-Id: ...

Ce qui, je pense, a besoin de l'en-tête:

Access-Control-Allow-Origin: *

Quelqu'un peut-il m'aider? Pourquoi est-ce un problème sur Firefox et non sur Chrome? Comment puis-je le résoudre?

Tout d'abord, vous devez vous assurer que l'en-tête d'origine de la liste blanche:

Si vous souhaitez que CloudFront respecte les paramètres de partage des ressources d'origine croisée, configurez CloudFront pour transférer l'en-tête Origin vers votre origine.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-cors

Voir également: http://aws.amazon.com/blogs/aws/enhanced-cloudfront-customization/

Au fait, il y a plusieurs questions similaires sur le défaut de serveur / stackoverflow et beaucoup de réponses.

C'est un peu plus compliqué que ne l'indique la réponse acceptée.

La prise en charge de CORS lors de l'utilisation de Cloudfront + S3 est en fait implémentée dans S3 et fonctionne comme suit selon Amazon:

L'en-tête Origin de la demande doit correspondre à un élément AllowedOrigin.

La méthode de demande (par exemple, GET ou PUT) ou l'en-tête Access-Control Request-Method dans le cas où une demande OPTIONS de contrôle en amont doit être l'un des éléments AllowedMethod.

Chaque en-tête répertorié dans l'en-tête Access-Control-Request-Headers de la demande sur la demande de contrôle en amont doit correspondre à un élément AllowedHeader.

Cela est logique, ce qui peut ne pas être clair, c'est que si aucun en-tête Origin n'est envoyé par le client, ce traitement n'est pas du tout effectué. Et nous utilisons Cloudfront en face qui, si vous hébergez uniquement des actifs statiques, vous l'avez probablement configuré pour ignorer tous les en-têtes lors de la mise en cache. Par conséquent, si la première demande à chaque fichier à partir d'un nœud périphérique spécifique n'inclut pas l'en-tête Origin, il mettra en cache la réponse sans l'en-tête Access-Control-Allow-Origin.

Le résultat est que la première demande entrante déterminera quels en-têtes sont retournés pour toutes les demandes jusqu'à l'expiration du cache.

Il existe plusieurs façons de résoudre ce problème.

• Configurez cloudfront pour effectuer une mise en cache conditionnelle basée sur l'en-tête "Origin".

Cela fonctionne bien si vous ne vous attendez qu'à quelques-unes ou à une seule origine, mais sinon votre taux de mise en cache pourrait devenir très mauvais.

• Utilisez Lambda @ edge pour définir de force les en-têtes, cela ne peut être effectué qu'une seule fois pour chaque demande d'origine (S3).

Entièrement flexible, mais ajoute des frais généraux et des coûts.

• Faites en sorte que cloudfront remplace l'en-tête "Origin" par une valeur fictive pour chaque demande.

Cela n'est vraiment utile que dans le cas "Access-Control-Allow-Origin: *" et c'est un peu un hack, mais c'est probablement la meilleure solution actuelle lors de l'hébergement d'actifs statiques sur cloudfront + S3.