Назначение атрибута crossorigin…?

В тегах изображений и сценариев.

Насколько я понимаю, вы можете получить доступ как к сценариям, так и к изображениям в других доменах. Итак, когда можно использовать этот атрибут?

Это когда вы хотите ограничить доступ других к вашим скриптам и изображениям?

Изображений:

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

Скрипты:

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

Изображения с поддержкой CORS можно повторно использовать в элементе без искажения. Допустимые значения:

Страница уже отвечает на ваш вопрос.

Если у вас есть изображение из разных источников, вы можете скопировать его на холст, но это «портит» холст, что мешает вам его прочитать (поэтому вы не можете «украсть» изображения, например, из интрасети, где сам сайт не имеет доступа к ). Однако с помощью CORS сервер, на котором хранится изображение, может сообщить браузеру, что разрешен доступ из разных источников, и, таким образом, вы можете получить доступ к данным изображения через холст.

В MDN также есть страница об этом: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image

Это когда вы хотите ограничить доступ других к вашим скриптам и изображениям?

Нет.

Ответ можно найти в спецификации .

Для img:

crossoriginАтрибут является Корс с помощью параметров атрибута . Его цель - разрешить использование изображений со сторонних сайтов, которые разрешают доступ из разных источников canvas.

и для script:

crossoriginАтрибут является Корс с помощью параметров атрибута . Для скриптов, полученных из других источников , он контролирует, будет ли отображаться информация об ошибках.

Вот как мы успешно использовали crossoriginатрибут it в scriptтеге:

У нас была проблема: мы пытались регистрировать ошибки js на сервере, используя window.onerror

Почти все ошибки, которые мы регистрировали, имели это сообщение: Script error.и мы получали очень мало информации о том, как решить эти js-ошибки.

Оказывается, нативная реализация в chrome для сообщения об ошибках

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

будет отправлять, messageкак Script error.если бы запрошенный статический актив нарушает политику браузера того же происхождения .

В нашем случае мы обслуживали статический актив с компакт-диска.

Мы решили это путем добавления crossoriginатрибута к scriptтегу.

PS Получил всю информацию из этого ответа

Если вы разрабатываете небольшой фрагмент кода локально и используете Chrome, возникает проблема. если ваша страница загружается с использованием URL-адреса вида «файл: // xxxx», то попытка использовать getImageData () на холсте не удастся и выдаст ошибку безопасности перекрестного происхождения, даже если ваше изображение извлекается из того же каталог на вашем локальном компьютере в качестве HTML-страницы, отображающей холст. Итак, если ваша HTML-страница получена, скажем:

файл: // D: /wwwroot/mydir/mytestpage.html

и ваш файл Javascript и изображения извлекаются, например:

файл: // D: /wwwroot/mydir/mycode.js

файл: // D: /wwwroot/mydir/myImage.png

тогда, несмотря на то, что эти вторичные объекты извлекаются из одного и того же источника, ошибка безопасности все равно возникает.

По какой-то причине вместо правильной установки источника Chrome устанавливает для атрибута origin необходимых сущностей значение «null», что делает невозможным тестирование кода с использованием getImageData (), просто открывая HTML-страницу в браузере и выполняя локальную отладку.

Кроме того, установка свойства crossOrigin изображения на «анонимный» не работает по той же причине.

Я все еще пытаюсь найти обходной путь для этого, но опять же, похоже, что локальная отладка выполняется разработчиками браузеров настолько болезненно, насколько это возможно.

Я только что попытался запустить свой код в Firefox, и Firefox понял, что мое изображение имеет то же происхождение, что и сценарии HTML и JS. Так что я бы приветствовал несколько советов о том, как обойти проблему в Chrome, так как на данный момент, пока Firefox работает, его отладчик мучительно медленный, вплоть до того, что от атаки отказа в обслуживании отделяется один шаг.

Я узнал, как убедить Google Chrome разрешить ссылки на file: //, не вызывая ошибки перекрестного происхождения.

Шаг 1. Создайте ярлык (Windows) или аналог в других операционных системах;

Шаг 2: Установите цель примерно так:

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

Этот специальный аргумент командной строки --allow-file-access-from-files сообщает Chrome разрешить вам использовать ссылки file: // на веб-страницы, изображения и т. Д., Не вызывая ошибок перекрестного происхождения каждый раз, когда вы пытаетесь их передать. изображения на холст HTML, например. Он работает в моей установке Windows 7, но стоит проверить, будет ли он работать в Windows 8/10 и различных дистрибутивах Linux. Если это так, проблема решена - автономная разработка возобновляется в обычном режиме.

Теперь я могу ссылаться на изображения и данные JSON из URI file: //, не вызывая ошибок перекрестного происхождения в Chrome, если я пытаюсь передать данные изображения на холст или передать данные JSON в элемент формы.