Scopo dell'attributo crossorigin ...?


88

In entrambi i tag immagine e script.

La mia comprensione era che puoi accedere sia agli script che alle immagini su altri domini. Quindi quando si usa questo attributo?

È questo quando vuoi limitare la capacità degli altri di accedere ai tuoi script e alle tue immagini?

Immagini:

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

Script:

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

Risposte:


31

Le immagini abilitate per CORS possono essere riutilizzate nell'elemento senza essere contaminate. I valori consentiti sono:

La pagina risponde già alla tua domanda.

Se hai un'immagine multiorigine puoi copiarla in una tela ma questo "macchia" la tela impedendoti di leggerla (quindi non puoi "rubare" immagini ad es. Da una intranet a cui il sito stesso non ha accesso ). Tuttavia, utilizzando CORS il server in cui è archiviata l'immagine può indicare al browser che l'accesso cross-origin è consentito e quindi è possibile accedere ai dati dell'immagine tramite una tela.

MDN ha anche una pagina su questo argomento: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image

È questo quando vuoi limitare la capacità degli altri di accedere ai tuoi script e alle tue immagini?

No.


2
L'ho letto mentre ho pubblicato il collegamento nella mia domanda. Non significa niente per me. La domanda era generale e includeva anche gli script.
Puffetta

Non credo che questa sia davvero una risposta alla domandaPurpose of the crossorigin attribute …?
Pmpr

53

La risposta può essere trovata nelle specifiche .

Per img:

L' crossoriginattributo è un attributo delle impostazioni CORS . Il suo scopo è quello di consentire l'utilizzo di immagini da siti di terze parti che consentono l'accesso cross-origin canvas.

e per script:

L' crossoriginattributo è un attributo delle impostazioni CORS . Controlla, per gli script ottenuti da altre origini , se le informazioni sull'errore verranno esposte.


7
Sembrano avere poco in comune, nonostante abbiano lo stesso nome. Uno riguarda il controllo degli errori, l'altro è per l'uso con canvas.
Puffetta

@ Smurfette: la cosa che hanno in comune è che modificano il funzionamento dell'elemento quando viene utilizzato da un'origine incrociata. Ma sì, sono davvero molto diversi altrimenti.
TJ Crowder

1
@ Smurfette: questo non riguarda il fatto che ti impediscano di usare le immagini, ma che ti impediscano (o permettano) di usarle negli canvaselementi.
TJ Crowder

Solo per FYI che questo attributo è utile anche negli elementi di collegamento: quando ci si collega a un foglio di stile esterno in Firefox (ad esempio utilizzando i caratteri di Google), questo risolve i problemi che possono sorgere se si dispone di script che accedono a document.styleSheets
kinakuta

@ Smurfette: esiste un simile attributo per iFrame in modo che io possa controllare src dal lato server, se la richiesta proviene da Origin o no?
akashPatra

34

Ecco come abbiamo utilizzato con successo l' crossoriginattributo in un scripttag:

Problema che abbiamo avuto: stavamo cercando di registrare gli errori js nel server utilizzando window.onerror

Quasi tutti gli errori che stavamo registrando avevano questo messaggio: Script error.e stavamo ottenendo pochissime informazioni su come risolvere questi errori js.

Si scopre che l'implementazione nativa in Chrome per segnalare errori

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

invierà messagecome Script error.se l'asset statico richiesto violasse la norma della stessa origine del browser .

Nel nostro caso stavamo servendo l'asset statico da un cdn.

Il modo in cui lo abbiamo risolto è stato l'aggiunta crossorigindell'attributo al scripttag.

PS Ho ottenuto tutte le informazioni da questa risposta


4

Se stai sviluppando un breve pezzo di codice localmente e stai utilizzando Chrome, c'è un problema. se la tua pagina viene caricata utilizzando un URL del modulo "file: // xxxx", il tentativo di utilizzare getImageData () sull'area di disegno non riuscirà e genererà l'errore di sicurezza cross-origin, anche se l'immagine viene recuperata dallo stesso directory sulla macchina locale come pagina HTML che esegue il rendering della tela. Quindi, se la tua pagina HTML viene recuperata da, dì:

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

e il file e le immagini Javascript vengono recuperati da, ad esempio:

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

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

quindi, nonostante il fatto che queste entità secondarie vengano recuperate dalla stessa origine, l'errore di sicurezza viene comunque generato.

Per qualche motivo, invece di impostare correttamente l'origine, Chrome imposta l'attributo di origine delle entità richieste su "null", rendendo impossibile testare il codice che coinvolge getImageData () semplicemente aprendo la pagina HTML nel browser ed eseguendo il debug in locale.

Inoltre, l'impostazione della proprietà crossOrigin dell'immagine su "anonymous" non funziona, per lo stesso motivo.

Sto ancora cercando di trovare una soluzione per questo, ma ancora una volta, sembra che il debug locale sia reso il più doloroso possibile dagli implementatori del browser.

Ho appena provato a eseguire il mio codice in Firefox, e Firefox lo fa bene, riconoscendo che la mia immagine ha la stessa origine degli script HTML e JS. Quindi gradirei qualche suggerimento su come aggirare il problema in Chrome, poiché al momento, mentre Firefox funziona, il suo debugger è dolorosamente lento, al punto da essere rimosso a un passo da un attacco di negazione del servizio.


1
Grazie, questa risposta mi ha fatto capire che il problema che avevo potrebbe interessare solo l'ambiente di test locale, e lo era.
user1032613

1

Ho scoperto come persuadere Google Chrome a consentire file: // riferimenti senza generare un errore di origine incrociata.

Passaggio 1: creare un collegamento (Windows) o equivalente in altri sistemi operativi;

Passaggio 2: imposta l'obiettivo su qualcosa come il seguente:

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

Quello speciale argomento della riga di comando, --allow-file-access-from-files, dice a Chrome di farti usare file: // riferimenti a pagine web, immagini ecc., Senza generare errori cross-origin ogni volta che provi a trasferirli immagini su una tela HTML, ad esempio. Funziona sulla mia configurazione di Windows 7, ma vale la pena controllare per vedere se funzionerà anche su Windows 8/10 e varie distribuzioni Linux. In caso affermativo, problema risolto: lo sviluppo offline riprende normalmente.

Ora posso fare riferimento a immagini e dati JSON da file: // URI, senza che Chrome generi errori cross-origin se tento di trasferire i dati dell'immagine su una tela o trasferisco i dati JSON a un elemento del modulo.

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.