¿Propósito del atributo crossorigin…?

Respuestas:

31

Las imágenes habilitadas para CORS se pueden reutilizar en el elemento sin estar contaminadas. Los valores permitidos son:

La página ya responde a tu pregunta.

Si tiene una imagen de origen cruzado, puede copiarla en un lienzo, pero esto "mancha" el lienzo, lo que le impide leerlo (por lo que no puede "robar" imágenes, por ejemplo, de una intranet a la que el sitio no tiene acceso ). Sin embargo, al usar CORS, el servidor donde se almacena la imagen puede decirle al navegador que se permite el acceso de origen cruzado y, por lo tanto, puede acceder a los datos de la imagen a través de un lienzo.

MDN también tiene una página sobre esto: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image

¿Es aquí cuando desea restringir la capacidad de otros para acceder a sus scripts e imagen?

No.

ThiefMaster
fuente
2
Lo leí cuando publiqué el enlace en mi pregunta. No significa nada para mi. La pregunta era general y también incluía guiones.
Pitufina
No creo que esto sea realmente una respuesta a la preguntaPurpose of the crossorigin attribute …?
Pmpr
52

La respuesta se puede encontrar en la especificación .

Para img:

El crossoriginatributo es un atributo de configuración CORS . Su propósito es permitir el uso de imágenes de sitios de terceros que permiten el acceso de origen cruzado canvas.

y para script:

El crossoriginatributo es un atributo de configuración CORS . Controla, para los scripts que se obtienen de otros orígenes , si se expondrá la información de error.

TJ Crowder
fuente
6
Parece que tienen poco en común, a pesar de tener el mismo nombre. Uno se refiere al control de errores, el otro es para usar con lienzo.
Pitufina
@Smurfette: Lo que tienen en común es que modifican cómo funciona el elemento cuando se usa desde un origen cruzado. Pero sí, de hecho son bastante diferentes de lo contrario.
TJ Crowder
1
@Smurfette: Esto no se refiere a ellos el bloqueo que el uso de las imágenes, simplemente evitando (o permitir) el uso de ellos en canvaselementos.
TJ Crowder
Solo para su información, este atributo también es útil en elementos de enlace: cuando se vincula a una hoja de estilo externa en Firefox (por ejemplo, utilizando fuentes de Google), esto soluciona problemas que pueden surgir si tiene algún script que acceda a document.styleSheets
kinakuta
@Smurfette: ¿Existe algún atributo de este tipo para iFrame para que pueda controlar el src desde el lado del servidor, si la solicitud proviene de un origen conocido o no?
AkashPatra
33

Así es como hemos utilizado con éxito el crossoriginatributo en una scriptetiqueta:

Problema que tuvimos: estábamos tratando de registrar errores js en el servidor usando window.onerror

Casi todos los errores que estábamos registrando tenían este mensaje: Script error.y obteníamos muy poca información sobre cómo resolver estos errores de js.

Resulta que la implementación nativa en Chrome para reportar errores

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

se enviará messagecomo Script error.si el activo estático solicitado violara la política del mismo origen del navegador .

En nuestro caso, estábamos sirviendo el activo estático desde un cdn.

La forma en que lo resolvimos fue agregando el crossoriginatributo a la scriptetiqueta.

PD Obtuve toda la información de esta respuesta

Omar Rayward
fuente
4

Si está desarrollando una parte rápida de código localmente y está usando Chrome, hay un problema. si su página se carga usando una URL del formulario "file: // xxxx", entonces el intento de usar getImageData () en el lienzo fallará y arrojará el error de seguridad de origen cruzado, incluso si su imagen se está obteniendo del mismo directorio en su máquina local como la página HTML que representa el lienzo. Entonces, si se obtiene su página HTML, diga:

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

y su archivo Javascript e imágenes se están obteniendo de, digamos:

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

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

luego, a pesar del hecho de que estas entidades secundarias se obtienen del mismo origen, el error de seguridad sigue apareciendo.

Por alguna razón, en lugar de establecer el origen correctamente, Chrome establece el atributo de origen de las entidades necesarias en "nulo", lo que hace imposible probar el código que involucra getImageData () simplemente abriendo la página HTML en su navegador y depurando localmente.

Además, establecer la propiedad crossOrigin de la imagen en "anónimo" no funciona, por la misma razón.

Todavía estoy tratando de encontrar una solución para esto, pero una vez más, parece que los implementadores del navegador hacen que la depuración local sea lo más dolorosa posible.

Intenté ejecutar mi código en Firefox, y Firefox lo hace bien, reconociendo que mi imagen es del mismo origen que los scripts HTML y JS. Así que agradecería algunas sugerencias sobre cómo solucionar el problema en Chrome, ya que en este momento, mientras Firefox funciona, su depurador es dolorosamente lento, hasta el punto de estar a un paso de un ataque de denegación de servicio.

David Edwards
fuente
1
Gracias, esta respuesta me hizo darme cuenta de que el problema que tenía podría afectar solo al entorno de prueba local, y así fue.
user1032613
1

Descubrí cómo persuadir a Google Chrome para que permita referencias a file: // sin generar un error de origen cruzado.

Paso 1: Cree un acceso directo (Windows) o el equivalente en otros sistemas operativos;

Paso 2: establezca el objetivo en algo como lo siguiente:

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

Ese argumento de línea de comando especial, --allow-file-access-from-files, le dice a Chrome que le permita usar file: // referencias a páginas web, imágenes, etc., sin arrojar errores de origen cruzado cada vez que intente transferirlos. imágenes a un lienzo HTML, por ejemplo. Funciona en mi configuración de Windows 7, pero vale la pena verificar si funcionará en Windows 8/10 y también en varias distribuciones de Linux. Si es así, problema resuelto: el desarrollo fuera de línea se reanuda con normalidad.

Ahora puedo hacer referencia a imágenes y datos JSON desde file: // URI, sin que Chrome arroje errores de origen cruzado si intento transferir datos de imagen a un lienzo o transferir datos JSON a un elemento de formulario.

David Edwards
fuente