Objectif de l'attribut crossorigin…?

Dans les balises d'image et de script.

Je crois comprendre que vous pouvez accéder à la fois aux scripts et aux images sur d'autres domaines. Alors, quand utilise-t-on cet attribut?

Est-ce lorsque vous souhaitez limiter la capacité des autres d'accéder à vos scripts et à votre image?

Images:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin

Scripts:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script

Les images compatibles CORS peuvent être réutilisées dans l'élément sans être altérées. Les valeurs autorisées sont:

La page répond déjà à votre question.

Si vous avez une image d'origine croisée, vous pouvez la copier dans un canevas mais cela "souille" le canevas ce qui vous empêche de le lire (vous ne pouvez donc pas "voler" des images, par exemple depuis un intranet où le site lui-même n'a pas accès à ). Cependant, en utilisant CORS, le serveur sur lequel l'image est stockée peut indiquer au navigateur que l'accès à l'origine croisée est autorisé et que vous pouvez ainsi accéder aux données d'image via un canevas.

MDN a également une page sur cette chose: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image

Est-ce lorsque vous souhaitez limiter la capacité des autres d'accéder à vos scripts et à votre image?

Non.

La réponse se trouve dans la spécification .

Pour img:

L' crossoriginattribut est un attribut de paramètres CORS . Son objectif est d'autoriser l'utilisation d'images provenant de sites tiers permettant un accès cross-origin canvas.

et pour script:

L' crossoriginattribut est un attribut de paramètres CORS . Il contrôle, pour les scripts obtenus d'autres origines , si les informations d'erreur seront exposées.

Voici comment nous avons utilisé avec succès l' crossoriginattribut dans une scriptbalise:

Problème que nous avons eu: nous essayions de consigner les erreurs js sur le serveur en utilisant window.onerror

Presque toutes les erreurs que nous enregistrions avaient ce message: Script error.et nous obtenions très peu d'informations sur la façon de résoudre ces erreurs js.

Il s'avère que l'implémentation native dans Chrome pour signaler les erreurs

if (securityOrigin()->canRequest(targetUrl)) {
        message = errorMessage;
        line = lineNumber;
        sourceName = sourceURL;
} else {
        message = "Script error.";
        sourceName = String();
        line = 0;
}

enverra messagecomme Script error.si l'élément statique demandé enfreignait la politique de même origine du navigateur .

Dans notre cas, nous servions l'actif statique à partir d'un cdn.

La façon dont nous l'avons résolu a été d'ajouter l' crossoriginattribut à la scriptbalise.

PS J'ai toutes les informations de cette réponse

Si vous développez un morceau de code rapide localement et que vous utilisez Chrome, il y a un problème. si votre page se charge en utilisant une URL de la forme "file: // xxxx", alors essayer d'utiliser getImageData () sur le canevas échouera et lèvera l'erreur de sécurité cross-origin, même si votre image est extraite de la même répertoire sur votre machine locale en tant que page HTML rendant le canevas. Donc, si votre page HTML est extraite, dites:

fichier: // D: /wwwroot/mydir/mytestpage.html

et votre fichier Javascript et vos images sont récupérés, par exemple:

fichier: // D: /wwwroot/mydir/mycode.js

fichier: // D: /wwwroot/mydir/myImage.png

alors malgré le fait que ces entités secondaires sont extraites de la même origine, l'erreur de sécurité est toujours levée.

Pour une raison quelconque, au lieu de définir correctement l'origine, Chrome définit l'attribut d'origine des entités requises sur «null», ce qui rend impossible le test du code impliquant getImageData () simplement en ouvrant la page HTML dans votre navigateur et en déboguant localement.

En outre, définir la propriété crossOrigin de l'image sur "anonyme" ne fonctionne pas, pour la même raison.

J'essaie toujours de trouver une solution de contournement pour cela, mais encore une fois, il semble que le débogage local soit rendu aussi pénible que possible par les implémenteurs de navigateur.

J'ai juste essayé d'exécuter mon code dans Firefox, et Firefox le fait bien, en reconnaissant que mon image est de la même origine que les scripts HTML et JS. Je serais donc heureux de recevoir quelques conseils sur la façon de contourner le problème dans Chrome, car pour le moment, alors que Firefox fonctionne, son débogueur est extrêmement lent, au point d'être une étape supprimée d'une attaque par déni de service.

J'ai découvert comment persuader Google Chrome d'autoriser les références file: // sans générer d'erreur d'origine croisée.

Étape 1: Créez un raccourci (Windows) ou l'équivalent dans d'autres systèmes d'exploitation;

Étape 2: définissez la cible sur quelque chose comme ce qui suit:

"C: \ Program Files (x86) \ Google \ Chrome \ Application \ chrome.exe" - autoriser l'accès aux fichiers à partir des fichiers

Cet argument de ligne de commande spécial, --allow-file-access-from-files, indique à Chrome de vous permettre d'utiliser file: // références à des pages Web, des images, etc., sans générer d'erreurs d'origine croisée chaque fois que vous essayez de les transférer. images sur un canevas HTML, par exemple. Cela fonctionne sur ma configuration Windows 7, mais cela vaut la peine de vérifier si cela fonctionnera également sur Windows 8/10 et diverses distributions Linux. Si c'est le cas, problème résolu - le développement hors ligne reprend normalement.

Maintenant, je peux référencer des images et des données JSON à partir d'URI file: //, sans que Chrome génère des erreurs d'origine croisée si j'essaye de transférer des données d'image vers un canevas ou de transférer des données JSON vers un élément de formulaire.