Cela semble facile, mais je ne sais pas ce qui me manque.
J'ai un bucket public avec un script js que je récupère sur mon site Web. J'ai remarqué que je n'envoie pas l'en-tête Origin à S3, ce n'est pas obligatoire et tout fonctionne sans aucune configuration CORS.
De plus, même après avoir ajouté manuellement l'en-tête Origin à cet appel GET et explicitement interdit GET et mon domaine via:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>http://www.nonexistingdomain.com</AllowedOrigin>
<AllowedMethod>POST</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>
Je peux toujours obtenir le contenu. Que se passe-t-il ici?
3 Réponses :
La politique de même origine est une fonctionnalité appliquée par les navigateurs qui empêche JavaScript exécuté sur un site Web de lire les données d'un autre site Web. (Cela empêche les sites Web aléatoires d'utiliser JavaScript pour utiliser votre navigateur pour ignorer votre pare-feu d'entreprise et accéder à votre intranet ou lire votre GMail avec vos cookies).
CORS permet à un site Web d'assouplir la politique de même origine pour permettre à d'autres sites Web de lire les données de cette manière.
CORS n'est pas une authentification / autorisation. Votre bucket public est public .
Vous n'utilisez pas JavaScript pour lire les données de votre bucket, vous chargez le JS directement depuis le bucket.
J'utilise js pour charger les autres js. C'est un moyen de m'assurer que mon code de suivi n'est chargé qu'une seule fois.
Je n'ai pas dit que CORS avait quoi que ce soit à voir avec auth.
Bien que CORS soit appliqué par le navigateur, c'est avant tout un mécanisme de protection d'un serveur. Et le serveur doit réagir en conséquence lorsque la requête avec en-tête Origin (ou pré-vol) est arrivée.
@ yuranos87 - Non. Il n'est pas du tout conçu pour protéger le serveur. La même politique d'origine est conçue pour empêcher Evil Site d'utiliser le navigateur de la victime pour lire des données d'un autre site qui sont censées être un secret gardé entre l'autre site et la victime. CORS est conçu pour permettre à un autre site de permettre au site de confiance d'accéder à ces données secrètes (ou pour dire que les données ne sont pas du tout secrètes).
Eh bien, c'est ce que je voulais dire. Peut-être que «protéger le serveur» n'est pas la manière la plus précise de le dire, mais il s'agit de protéger les données qui se trouvent sur le serveur. "Lire les données d'un autre site" - concerne les données sur le serveur après tout.
En tout cas, cela ne répond malheureusement pas à ma question initiale.
Et le chargement de JS ne lit pas les données. Le chargement d'une image avec
ne l'est pas non plus.
Cela répond à votre question. Vous pouvez obtenir le contenu parce que vous chargez JS et non pas lire des données.
Ok, c'est intéressant. En quoi est-ce différent? C'est toujours un HTTP GET. S'il existe un moyen pour le navigateur de distinguer s'il s'agit d'un chargement