Quando dovrei usare l'attributo "crossorigin" su un <link> "preconnect"?


14

Vorrei includere alcuni suggerimenti sulle risorse di preconnessione sul mio sito in modo che i browser possano (ad esempio) connettersi alla CDN jQuery prima di vedere effettivamente il tag di script che richiama la CDN. Non sono sicuro se dovrei includere l'attributo "crossorigin" o quale dovrebbe essere il suo valore. Le specifiche dicono, in parte,

Per avviare una preconnessione, l'agente utente deve eseguire questi passaggi:

[...]

  1. Lascia che corsAttributeState sia lo stato corrente dell'attributo crossorigincontent dell'elemento .
  2. Consenti alle credenziali di essere un valore booleano impostato su true.
  3. Se corsAttributeState è Anonymouse l' origine non è uguale all'origine del documento corrente, impostare le credenziali su false.
  4. Tentare di ottenere la connessione con l' origine e le credenziali .

Non so come interpretare questo algoritmo. Se mi preconnetto a un CDN, che consentirà a chiunque di scaricare il suo contenuto senza alcun tipo di credenziali, quale valore dovrei usare per l'attributo "crossorigin"?


Risposte:


4

Stavo cercando la stessa cosa e ho trovato questo

Indica qui che se non si utilizza l'attributo cross origine, l'agente utente esegue semplicemente la ricerca DNS ma non stabilisce una connessione con il dominio specifico. Quindi l'attributo crossorigin è necessario se devi preconnetterti a cross domain, in questo modo:

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

Inoltre, se si desidera inviare alcune credenziali a quel particolare dominio incrociato, è possibile impostare il valore su origine incrociata, crossorigin = use-credentialsaltrimenti penso che il valore predefinito sia anonimo.


Questo è mezzo vero. Se si utilizza CORS (come accade con i caratteri), verrà utilizzata solo la ricerca DNS con la richiesta del carattere. (La connessione si verifica comunque, ma non viene mostrata nel grafico a cascata perché è necessario aprire una connessione separata per la richiesta CORS .) Se si sta recuperando uno script, l'utilizzo crossoriginsprecherà in modo simile una connessione, poiché è necessario aprire una nuova connessione che non usa CORS.
Michael Crenshaw,

2

Finora capisco l'uso di crossorigin, specialmente in termini di valori anonymouse use-credentials, dovresti usare crossorigin="use-credentials"nel caso:

  • usi risorse, come immagini o video, che hanno un attributo crossorigin
  • si prevede di trasportare cookie, autenticazione HTTP e certificati SSL lato client tra le origini, in base alle precedenti interazioni dell'agente utente con l'origine.

Oltre alla documentazione citata da te, ho ottenuto questo e quello . Ma in effetti la documentazione è fuorviante e contiene errori di ortografia: il primo lo chiama use-credentials, il secondo - user-credentials.

Comunque, nella mia comprensione:

  • no è crossoriginuguale a tutticrossorigin="anonymous"
  • crossorigin equivale crossorigin="use-credentials"

Forse qualcuno mi correggerebbe.

PS : la versione corrente della pagina Mozilla sull'argomento significa:

Una parola chiave non valida e una stringa vuota verranno gestite come parola chiave anonima.

Mezzi: no crossorigin, crossorigino crossorigin="use_credentials"sono tutti gestiti come crossorigin="anonymous".


5
Credo, come menzionato in MDN , per impostazione predefinita (ovvero quando l'attributo non è specificato), CORS non viene utilizzato affatto. Inoltre, solo l'impostazione crossoriginè uguale a crossorigin="anonymous".
Shakespear,

1

Dipende da due cose:

  1. Il tipo di risorse da scaricare (che determina se verrà utilizzato CORS)
  2. Se il server di destinazione utilizza le credenziali per le connessioni CORS

Per jQuery, non useresticrossorigin . Gli script non sono tra i tipi di risorse che i browser utilizzano CORS per scaricare .

I caratteri, d'altra parte, usano CORS.

  • Se la pagina recupererà solo risorse che utilizzano CORS, includere l' crossoriginattributo.
  • Se la pagina recupererà solo risorse che non utilizzano CORS, ometti crossorigin. Se
  • Se la pagina preleverà entrambi i tipi di risorse, si potrebbe essere bisogno di due suggerimenti di risorse . (Informativa completa, il link è al mio sito personale. :-)) Qualcuno ha sottolineato che potresti non aver bisogno di due suggerimenti per HTTP / 2. Non ho avuto il tempo di testare.

Ecco il post Stack Overflow in cui ho riscontrato lo stesso problema.

Non mi sono tuffato quando sono necessarie le credenziali CORS. Non ho visto un esempio in cui sono necessari, quindi è probabile che tu sia al sicuro crossorigin(ad esempio, "crossorigin =" anonimo ").


1

Tutte le risposte finora sembrano semplificate, incomplete o parzialmente errate (l'argomento è complesso, le cose hanno un nome confuso e non sono ben documentate!), Quindi ecco la mia comprensione:

Per poter riutilizzare la connessione creata da <link rel=preconnect>, le cose dipendono dal tipo di contenuto che si desidera recuperare, da dove, se la richiesta invierà le credenziali del browser (che possono essere stabilite dal browser in modo esplicito o implicito):

La richiesta è della stessa origine ( example.comrichiede risorse secondarie da example.com)

In preconnectprimo luogo non è necessario affatto; il browser mantiene aperta la connessione dopo aver caricato la pagina per un bel po '. Se ci sono più connessioni da aprire, il browser decide da solo se e quante aprire (a seconda se il server annuncia il supporto HTTP / 2 nell'handshake TLS, nelle impostazioni del browser ecc.)

da verificare : cosa succede se la richiesta della stessa origine ha un crossoriginattributo: viene utilizzata o ignorata?

La richiesta è di origine incrociata ( example.comrichiede risorse secondarie da another.com)

  • se la richiesta effettiva ha l' crossoriginattributo esplicitamente impostato in HTML ( crossOriginin JS - il caso è importante), anche la preconnessione deve averlo, con lo stesso valore (forse tranne nei casi in cui non ha senso e crossoriginviene ignorato - non del tutto chiaro per io ancora)
  • altrimenti, se richiesto se per <script type=module>: da verificare
  • altrimenti, se la richiesta è e richiesta di "vecchia scuola" per <img>, <style type=stylesheet>, <iframe>, classico <script>ecc (avviato tramite HTML o JS) , senza crossoriginesplicitamente specificato , allora il preconnect non deve aver crossoriginimpostato l'attributo.
  • altrimenti, se la richiesta è una richiesta di font di origine incrociata , deve essere presente la preconnessionecrossorigin=anonymous
  • altrimenti, se la richiesta è di origine incrociata fetch o XHR:
    • se viene eseguito in modalità credenziale (ovvero i cookie sono collegati o viene utilizzata l'autenticazione HTTP di base; in caso di recupero, ciò significa credentials !== omit; in caso di XHR withCredentials === true:): preconnect deve averecrossorigin=use-credentials
    • se non è in modalità credenziale: deve avere la preconnessione crossorigin=anonymous

Per l'ultimo caso (fetch / XHR), vai al pannello di rete in Chrome / Firefox devtools, fai clic con il pulsante destro del mouse su una richiesta e scegli copy as fetchda un menu a discesa. Questo creerà uno snippet di JS, che ti dirà se quella richiesta è CORS-enabled ( "mode"=="cors") e credentialed ( "credentials"=="include"|"same-origin").

Nota, tuttavia, il trucco di cui sopra non funziona correttamente per le richieste non XHR / fetch, perché ad esempio fetche <img>utilizza algoritmi diversi per stabilire la connessione, come spiegato prima.

Infine, in HTML, <link ...crossorigin>=== <link ...crossorigin=anonymous>.

Note e collegamenti aggiuntivi:

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.