Cel atrybutu crossorigin…?

W tagach obrazu i skryptu.

Zrozumiałem, że możesz uzyskać dostęp zarówno do skryptów, jak i obrazów w innych domenach. Kiedy więc używa się tego atrybutu?

Czy dzieje się tak, gdy chcesz ograniczyć innym osobom dostęp do Twoich skryptów i obrazu?

Zdjęcia:

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

Skrypty:

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

Obrazy z obsługą CORS mogą być ponownie używane w elemencie bez skażenia. Dozwolone wartości to:

Strona już odpowiada na Twoje pytanie.

Jeśli masz obraz pochodzący z różnych źródeł, możesz go skopiować na płótno, ale to „plami” płótno, co uniemożliwia jego odczyt (więc nie możesz „ukraść” obrazów np. Z intranetu, do którego sama witryna nie ma dostępu ). Jednak przy użyciu mechanizmu CORS serwer, na którym przechowywany jest obraz, może poinformować przeglądarkę, że dostęp między źródłami jest dozwolony, a zatem można uzyskać dostęp do danych obrazu za pośrednictwem kanwy.

MDN ma również stronę poświęconą temu właśnie: https://developer.mozilla.org/en-US/docs/HTML/CORS_Enabled_Image

Czy dzieje się tak, gdy chcesz ograniczyć innym osobom dostęp do Twoich skryptów i obrazu?

Nie.

Odpowiedź można znaleźć w specyfikacji .

Dla img:

crossoriginAtrybut jest atrybutem Cors ustawieniach . Jego celem jest umożliwienie używania obrazów z witryn innych firm, które umożliwiają dostęp do różnych źródeł canvas.

i dla script:

crossoriginAtrybut jest atrybutem Cors ustawieniach . W przypadku skryptów uzyskiwanych z innych źródeł kontroluje, czy informacje o błędach zostaną ujawnione.

Oto, jak z powodzeniem wykorzystaliśmy crossoriginatrybut go w scripttagu:

Problem, który mieliśmy: próbowaliśmy rejestrować błędy js na serwerze przy użyciu window.onerror

Prawie wszystkie błędy, które rejestrowaliśmy, zawierały ten komunikat: Script error.otrzymywaliśmy bardzo mało informacji o tym, jak rozwiązać te błędy js.

Okazuje się, że natywna implementacja w chrome zgłasza błędy

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

wyśle messagetak, Script error.jakby żądany statyczny zasób naruszał zasady przeglądarki tego samego źródła .

W naszym przypadku obsługiwaliśmy statyczny zasób z cdn.

Sposób, w jaki to rozwiązaliśmy, polegał na dodaniu crossoriginatrybutu do scripttagu.

PS Mam wszystkie informacje z tej odpowiedzi

Jeśli tworzysz lokalnie szybki fragment kodu i używasz przeglądarki Chrome, jest problem. jeśli Twoja strona ładuje się przy użyciu adresu URL w postaci „file: // xxxx”, wówczas próba użycia metody getImageData () w obszarze roboczym zakończy się niepowodzeniem i zgłosi błąd zabezpieczeń między źródłami, nawet jeśli obraz jest pobierany z tego samego katalogu na komputerze lokalnym jako strona HTML renderująca płótno. Jeśli więc Twoja strona HTML jest pobierana z, powiedz:

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

a Twój plik JavaScript i obrazy są pobierane z, powiedzmy:

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

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

następnie pomimo faktu, że te drugorzędne jednostki są pobierane z tego samego źródła, nadal zgłaszany jest błąd zabezpieczeń.

Z jakiegoś powodu, zamiast prawidłowo ustawić źródło, Chrome ustawia atrybut origin wymaganych encji na „null”, uniemożliwiając testowanie kodu wykorzystującego metodę getImageData (), po prostu otwierając stronę HTML w przeglądarce i debugując lokalnie.

Z tego samego powodu nie działa też ustawienie właściwości crossOrigin obrazu na „anonymous”.

Nadal próbuję znaleźć obejście tego problemu, ale po raz kolejny wydaje się, że lokalne debugowanie jest renderowane tak bolesnie, jak to tylko możliwe przez implementatory przeglądarek.

Właśnie próbowałem uruchomić mój kod w przeglądarce Firefox i Firefox robi to dobrze, rozpoznając, że mój obraz pochodzi z tego samego źródła co skrypty HTML i JS. Dlatego z zadowoleniem przyjąłbym kilka wskazówek, jak obejść problem w Chrome, ponieważ w tej chwili, gdy Firefox działa, jego debugger jest boleśnie powolny, do tego stopnia, że ​​jest o jeden krok usuwany z ataku typu „odmowa usługi”.

Dowiedziałem się, jak przekonać Google Chrome, aby zezwolił na odwołania file: // bez zgłaszania błędu cross-origin.

Krok 1: Utwórz skrót (Windows) lub jego odpowiednik w innych systemach operacyjnych;

Krok 2: Ustaw cel na coś podobnego do następującego:

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

Ten specjalny argument wiersza poleceń, --allow-file-access-from-files, mówi Chrome, aby pozwolił Ci używać odwołań file: // do stron internetowych, obrazów itp., Bez generowania błędów między źródłami za każdym razem, gdy próbujesz je przenieść na przykład obrazy na kanwę HTML. Działa na mojej konfiguracji systemu Windows 7, ale warto sprawdzić, czy będzie działać również w systemie Windows 8/10 i różnych dystrybucjach Linuksa. Jeśli tak, problem został rozwiązany - programowanie offline zostaje wznowione normalnie.

Teraz mogę odwoływać się do obrazów i danych JSON z identyfikatorów URI file: //, bez generowania przez Chrome błędów między źródłami, jeśli próbuję przenieść dane obrazu do kanwy lub przenieść dane JSON do elementu formularza.