Objectif de l'attribut crossorigin... ?

Question

Dans les balises image et script.

J'ai cru comprendre que vous pouviez accéder à la fois aux scripts et aux images sur d'autres domaines. Alors quand utilise-t-on cet attribut ?

Est-ce à ce moment que vous voulez restreindre la capacité des autres à 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

Answer 1

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

Para img :

Le site crossorigin est un attribut Attribut de paramètres CORS . Son objectif est de permettre l'utilisation d'images provenant de sites tiers qui autorisent l'accès d'origine croisée avec canvas .

et pour script :

Le site crossorigin est un attribut Attribut de paramètres CORS . Il contrôle, pour les scripts qui sont obtenus à partir d'autres origines si les informations relatives aux erreurs seront exposées.

Answer 2

Voici comment nous avons utilisé avec succès crossorigin l'attribuer dans un script étiquette :

Problème rencontré : Nous avons essayé d'enregistrer les erreurs de js dans le serveur en utilisant window.onerror

Presque toutes les erreurs que nous enregistrions comportaient ce message : Script error. et nous recevions très peu d'informations sur la façon de résoudre ces erreurs de 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 message comme Script error. si l'actif statique demandé viole les règles de sécurité du navigateur. politique d'origine commune .

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

La façon dont nous avons résolu ce problème a été d'ajouter le crossorigin de l'attribut script étiquette.

P.S. J'ai obtenu toutes les informations auprès de cette réponse

Answer 3

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 disposez d'une image d'origine croisée, vous pouvez la copier dans un canevas, mais cela "entache" le canevas, ce qui vous empêche de le lire (vous ne pouvez donc pas "voler" des images, par exemple d'un intranet auquel le site lui-même n'a pas accès). Toutefois, en utilisant CORS, le serveur où l'image est stockée peut indiquer au navigateur que l'accès d'origine croisée est autorisé et que vous pouvez donc accéder aux données de l'image par le biais d'un canevas.

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

Est-ce à ce moment que vous voulez restreindre la capacité des autres à accéder à vos scripts et à votre image ?

No.

Answer 4

Si vous développez un petit bout de code 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", l'utilisation de la fonction getImageData() sur le canevas échouera et provoquera une erreur de sécurité d'origine croisée, même si votre image est récupérée dans le même répertoire sur votre machine locale que la page HTML qui rend le canevas. Donc, si votre page HTML est récupérée à partir de, disons :

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

et votre fichier Javascript et les images sont récupérés à partir de, disons :

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

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

alors, malgré le fait que ces entités secondaires sont récupérées à partir de la même origine, l'erreur de sécurité est toujours déclenchée.

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

De même, le fait de définir la propriété crossOrigin de l'image sur "anonymous" ne fonctionne pas, pour la même raison.

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

Je viens d'essayer d'exécuter mon code dans Firefox, et Firefox s'en sort bien, en reconnaissant que mon image a la même origine que les scripts HTML et JS. J'aimerais donc avoir des conseils sur la façon de contourner le problème dans Chrome, car pour le moment, bien que Firefox fonctionne, son débogueur est le suivant douloureusement lent, au point d'être à deux doigts d'une attaque par déni de service.

Answer 5

J'ai découvert comment persuader Google Chrome d'autoriser les références file:// sans déclencher une 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 comme suit :

" C:\Program Fichiers (x86) \Google\Chrome\Application\chrome.exe " --allow-file-access-from-files

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

Je peux désormais référencer des images et des données JSON à partir d'URI file://, sans que Chrome n'émette d'erreur d'origine croisée si je tente de transférer des données d'image vers un canevas ou des données JSON vers un élément de formulaire.