Cel atrybutu crossorigin…?


88

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

Odpowiedzi:


31

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.


2
Przeczytałem to, kiedy zamieściłem link w moim pytaniu. To nic dla mnie nie znaczy. Pytanie było ogólne i obejmowało również skrypty.
Smurfette

Nie sądzę, żeby to rzeczywiście była odpowiedź na pytaniePurpose of the crossorigin attribute …?
Pmpr

52

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.


6
Wydaje się, że mają niewiele wspólnego, pomimo tego samego imienia. Jeden dotyczy kontroli błędów, a drugi dotyczy płótna.
Smurfette

@Smurfette: Łączy je to, że modyfikują sposób działania elementu, gdy jest używany z innego źródła. Ale tak, poza tym rzeczywiście są zupełnie inne.
TJ Crowder

1
@Smurfette: Nie dotyczy to blokowania ich przed użyciem obrazów, po prostu uniemożliwiających (lub zezwalających) na używanie ich w canvaselementach.
TJ Crowder

Tylko informacja dla Twojej wiadomości, że ten atrybut jest również przydatny w elementach linków - podczas tworzenia linków do zewnętrznego arkusza stylów w Firefoksie (np. Przy użyciu czcionek Google) rozwiązuje to problemy, które mogą się pojawić, jeśli masz jakiekolwiek skrypty, które uzyskują dostęp do document.styleSheets
kinakuta

@Smurfette: Czy istnieje taki atrybut dla iFrame, żebym mógł kontrolować src po stronie serwera, jeśli żądanie pochodzi ze znanego źródła, czy nie?
akashPatra

33

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


4

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”.


1
Dzięki, ta odpowiedź uświadomiła mi, że problem, który miałem, mógł wpływać tylko na lokalne środowisko testowe i tak było.
user1032613

1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.