Je voudrais inclure quelques conseils de ressources de préconnexion sur mon site afin que les navigateurs puissent (par exemple) se connecter au CDN jQuery avant de voir réellement la balise de script qui appelle le CDN. Je ne sais pas si je dois inclure l'attribut «crossorigin» ou quelle devrait être sa valeur. La spécification dit, en partie,

Pour lancer une préconnexion, l'agent utilisateur doit exécuter ces étapes:

[…]

3. Soit corsAttributeState l'état actuel de l' crossoriginattribut content de l'élément .
4. Soit les informations d'identification une valeur booléenne définie sur true.
5. Si corsAttributeState est Anonymouset que l' origine n'est pas égale à l'origine du document actuel, définissez les informations d'identification sur false.
6. Essayez d'obtenir une connexion avec l' origine et les informations d'identification .

Je ne sais pas comment interpréter cet algorithme. Si je me connecte à un CDN, ce qui permettra à quiconque de télécharger son contenu sans aucune sorte d'informations d'identification, quelle valeur dois-je utiliser pour l'attribut «crossorigin»?

Je cherchais la même chose et j'ai trouvé ça

Il indique ici que si vous n'utilisez pas l'attribut cross origin, l'agent utilisateur effectue simplement la recherche DNS mais n'établit pas de connexion avec le domaine particulier. L'attribut crossorigin est donc nécessaire si vous devez vous pré-connecter au domaine croisé, comme ceci:

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

De plus, si vous souhaitez envoyer des informations d'identification à ce domaine croisé particulier, vous pouvez définir la valeur sur crossorigin, crossorigin = use-credentialssinon je pense que la valeur par défaut est anonyme.

Jusqu'à présent, je comprends l'utilisation de crossorigin, en particulier en termes de valeurs anonymouset use-credentials, vous devez utiliser crossorigin="use-credentials"au cas où:

• vous utilisez des éléments, comme des images ou des vidéos, qui ont un attribut crossorigin
• vous prévoyez de transporter des cookies, une authentification HTTP et des certificats SSL côté client entre les origines, en fonction des interactions précédentes de l'agent utilisateur avec l'origine.

En plus de la documentation que vous avez citée, j'ai ceci et cela . Mais en effet, la documentation est trompeuse et contient des fautes d'orthographe: la première l'appelle use-credentials, la seconde - user-credentials.

Quoi qu'il en soit, à ma connaissance:

• pas crossorigindu tout égalcrossorigin="anonymous"
• crossorigin équivaut à crossorigin="use-credentials"

Peut-être que quelqu'un me corrigerait.

PS : La version actuelle de la page Mozilla au sujet signifie:

Un mot clé non valide et une chaîne vide seront traités comme mot clé anonyme.

Moyens: pas crossorigindu tout, crossoriginou crossorigin="use_credentials"sont tous traités comme crossorigin="anonymous".

Cela dépend de deux choses:

1. Le type d'actifs à télécharger (qui détermine si CORS sera utilisé)
2. Si le serveur cible utilise des informations d'identification pour les connexions CORS

Pour jQuery, vous n'utiliseriez pascrossorigin . Les scripts ne font pas partie des types de ressources que les navigateurs utilisent CORS pour télécharger .

Les polices, en revanche, utilisent CORS.

• Si la page ne récupère que les ressources qui utilisent CORS, incluez l' crossoriginattribut.
• Si la page ne récupère que les ressources qui n'utilisent pas CORS, omettez crossorigin. Si
• Si la page récupère les deux types de ressources, vous pouvez avoir besoin de deux conseils de ressources . (Divulgation complète, le lien est vers mon site personnel. :-)) Quelqu'un a fait remarquer que vous pourriez ne pas avoir besoin de deux conseils pour HTTP / 2. Je n'ai pas eu le temps de tester.

Voici le post Stack Overflow où j'ai rencontré le même problème.

Je n'ai pas plongé dans quand les informations d'identification CORS sont nécessaires. Je n'ai pas vu d'exemple où ils sont nécessaires, donc il y a de crossoriginfortes chances que vous soyez en sécurité (c'est-à-dire `crossorigin =" anonyme ").

Jusqu'à présent, toutes les réponses semblent soit simplifiées, incomplètes ou partiellement erronées (le sujet est complexe, les choses portent un nom confus et ne sont pas bien documentées!), Alors voici ma compréhension:

Pour pouvoir réutiliser la connexion créée par <link rel=preconnect>, les choses dépendent du type de contenu que vous souhaitez récupérer, d'où, si la demande enverra les informations d'identification du navigateur (qui peuvent être établies par le navigateur explicitement ou implicitement):

La demande est de même origine (les example.comdemandes proviennent de sous-ressources example.com)

Il n'y a aucun besoin du preconnecttout en premier lieu; le navigateur maintient la connexion ouverte après avoir chargé la page pendant un bon moment. S'il y a plusieurs connexions à ouvrir, le navigateur décide par lui-même si et combien à ouvrir (selon que le serveur annonce la prise en charge HTTP / 2 dans la négociation TLS, les paramètres du navigateur, etc.)

à vérifier : que faire si une requête de même origine a un crossoriginattribut: est-elle utilisée ou ignorée?

La demande est d' origine croisée (les example.comdemandes proviennent de sous-ressources another.com)

• si la demande réelle a un crossoriginattribut explicitement défini en HTML ( crossOrigindans JS - la casse est importante), la préconnexion doit également l'avoir, avec la même valeur (peut-être sauf dans les cas où cela n'a pas de sens et crossoriginest ignoré - pas complètement clair pour moi encore)
• sinon, si demande si pour <script type=module>: à vérifier
• Sinon, si la demande est et « vieille école » demande <img>, <style type=stylesheet>, <iframe>, classique , <script>etc. (initiée via HTML ou JS) sans crossoriginexplicitement spécifié , le MUST preconnect ne pas avoir crossoriginensemble d'attributs.
• sinon, si la demande est une demande de police d' origine croisée , la préconnexion doit avoircrossorigin=anonymous
• sinon, si la demande est d' origine croisée fetch ou XHR:
  • si cela se fait en mode authentifié (c'est-à-dire que des cookies sont attachés ou que l'authentification de base HTTP est utilisée; en cas de récupération, cela signifie credentials !== omit; en cas de XHR:): la préconnexion withCredentials === truedoit avoircrossorigin=use-credentials
  • s'il n'est pas en mode accrédité: la préconnexion doit avoir crossorigin=anonymous

Pour le dernier cas (fetch / XHR), accédez au panneau réseau dans les devtools Chrome / Firefox, cliquez avec le bouton droit sur une demande et choisissez copy as fetchdans une liste déroulante. Cela créera un extrait de JS, qui vous dira si cette demande est compatible CORS ( "mode"=="cors") et authentifiée ( "credentials"=="include"|"same-origin").

Notez cependant que l'astuce ci-dessus ne fonctionne pas correctement pour les demandes non XHR / fetch, car par exemple fetchet <img>utilisez différents algorithmes pour établir la connexion, comme expliqué précédemment.

Enfin, en HTML, <link ...crossorigin>=== <link ...crossorigin=anonymous>.

Notes et liens supplémentaires:

• dans Firefox, la préconnexion ne fonctionne pas même si elle est censée
• trois façons de vérifier si la préconnexion fonctionne
• les navigateurs ont certaines limites quant au nombre de requêtes DNS parallèles pouvant se produire
• expérimenter avec préconnexion avec injection de script personnalisé sur WebPageTest