web-dev-qa-db-fra.com

S3 ne renvoie pas les en-têtes Access-Control-Allow-Origin?

Je ne parviens pas à forcer S3 à définir des en-têtes CORS sur tous les objets renvoyés d'un compartiment, bien que CORS soit activé, car les téléchargements S3 côté client fonctionnent, les objets renvoyés ne possèdent pas d'en-têtes CORS!

La politique que j'ai activée est la suivante:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <AllowedMethod>POST</AllowedMethod>
        <AllowedMethod>PUT</AllowedMethod>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

Exemple d'URL d'objet https://s3.amazonaws.com/captionable/meme/test

Est-ce que quelqu'un sait ce qui ne va pas?

amazon-s3cors
27
Cory Dolphin

Tout d’abord, assurez-vous qu’un en-tête Origin est associé à chaque demande. Si aucun en-tête Origin n'est envoyé, S3 n'enverra pas les en-têtes access-control, car S3 les juge non pertinents (et ils le sont généralement). Un navigateur (auquel le mécanisme CORS est destiné) enverra automatiquement un en-tête Origin lors de l'exécution de demandes HTTP d'origine croisée via XMLHTTPRequest.

Si vous chargez des images avec img, vous devez ajouter l'attribut crossorigin="anonymous". Voir Documentation MDN sur l'attribut crossorigin . Ainsi, le navigateur enverra un en-tête de demande Origin comme il le fait avec XMLHTTPRequest.

Selon la réponse de Sam Selikoff, vous devrez peut-être changer 

 <AllowedOrigin>http://*</AllowedOrigin>

à

 <AllowedOrigin>http://*</AllowedOrigin>
 <AllowedOrigin>https://*</AllowedOrigin>

Je n'ai pas testé cela.

D'après le commentaire de Paul Draper sur cette réponse: Méfiez-vous des problèmes de mise en cache. Un navigateur peut utiliser une réponse en cache qui n'inclut pas les en-têtes de réponse Access-Control appropriés. Pendant le développement, vous pouvez vider votre cache. En production, vous devez basculer vers une nouvelle URL pour la ressource, si elle était utilisée de manière statique auparavant.

34
Myrne Stol

J'ai aussi rencontré cela avec une balise <image> et, après avoir suivi la réponse de Myrne Stol, j'ai ajouté la balise crossorigin=anonymous à ma balise d'image. J'ai vérifié que l'en-tête Origin était effectivement envoyé à S3, mais néanmoins, l'en-tête Access-Control-Allow-Origin n'était pas envoyé en réponse.

Je suis tombé sur cette SO réponse et cela a résolu le problème. J'ai changé la AllowedOrigin dans ma configuration S3 en ceci:

<AllowedOrigin>http://*</AllowedOrigin>
<AllowedOrigin>https://*</AllowedOrigin>

et maintenant S3 répond avec les en-têtes d'accès. Yay!

27
Sam Selikoff

TLDR; Assurez-vous que chaque élément d'image ou de vidéo qui demande une ressource qui (quelque part) a besoin de CORS utilise crossorigin="anonymous"

J'ai rencontré ce problème pour un élément vidéo qui exportait vers un canevas. Le CORS a été configuré correctement dans S3, mais il m’a tout de même provoqué une erreur et refusé de lire la vidéo.

Il s'est avéré qu'il y avait un deuxième élément vidéo pointant sur la même ressource et que l'élément vidéo n'avait pas crossorigin="anonymous". Par conséquent, la deuxième vidéo s'est bien déroulée, car elle ne s'attendait pas à un en-tête access-control, mais la réponse du serveur a été mise en cache et a bloqué la lecture de la première vidéo car la réponse du serveur en cache ne comportait pas de access-control header.

0
d2vid