画像タグとスクリプトタグの両方。
私の理解では、他のドメインのスクリプトとイメージの両方にアクセスできます。では、いつこの属性を使用するのでしょうか。
これは、他の人が自分のスクリプトや画像にアクセスする機能を制限したい場合ですか？
画像：
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
これは、他の人が自分のスクリプトや画像にアクセスする機能を制限したい場合ですか？
番号。
Purpose of the crossorigin attribute …?
canvas。要素での使用を防止（または許可）するだけです。
これはcrossorigin、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.
私たちの場合、cdnから静的アセットを提供していました。
それを解決する方法はcrossorigin、scriptタグに属性を追加することでした。
PSこの回答からすべての情報を入手しました
ローカルで簡単なコードを開発していて、Chromeを使用している場合は、問題があります。「file：// xxxx」の形式のURLを使用してページをロードすると、キャンバスでgetImageData（）を使用しようとすると失敗し、同じ画像からフェッチされている場合でも、クロスオリジンセキュリティエラーがスローされます。キャンバスをレンダリングするHTMLページとしてのローカルマシン上のディレクトリ。したがって、HTMLページがからフェッチされた場合、次のように言います。
file：// D：/wwwroot/mydir/mytestpage.html
そして、Javascriptファイルと画像は次のようにフェッチされています。
file：// D：/wwwroot/mydir/mycode.js
file：// D：/wwwroot/mydir/myImage.png
次に、これらのセカンダリエンティティが同じオリジンからフェッチされているにもかかわらず、セキュリティエラーがスローされます。
何らかの理由で、Chromeは原点を適切に設定する代わりに、必要なエンティティの原点属性を「null」に設定し、ブラウザでHTMLページを開いてローカルでデバッグするだけでは、getImageData（）を含むコードをテストできなくなります。
また、同じ理由で、画像のcrossOriginプロパティを「anonymous」に設定しても機能しません。
私はまだこれの回避策を見つけようとしていますが、もう一度、ローカルデバッグはブラウザの実装者によって可能な限り苦痛にされているようです。
Firefoxでコードを実行しようとしましたが、Firefoxは、私の画像がHTMLおよびJSスクリプトと同じ起源であることを認識して、正しく実行しました。ですから、Chromeで問題を回避する方法についてのヒントを歓迎します。現時点では、Firefoxは機能していますが、デバッガーは非常に遅く、サービス拒否攻撃から一歩離れています。
クロスオリジンエラーをスローせずにfile：//参照を許可するようにGoogleChromeを説得する方法を見つけました。
ステップ1：他のオペレーティングシステムでショートカット（Windows）または同等のものを作成します。
ステップ2：ターゲットを次のようなものに設定します。
"C：\ Program Files（x86）\ Google \ Chrome \ Application \ chrome.exe" --allow-file-access-from-files
その特別なコマンドライン引数--allow-file-access-from-filesは、Chromeに、Webページや画像などを転送しようとするたびにクロスオリジンエラーをスローせずに、file：//参照を使用できるようにするように指示します。たとえば、画像をHTMLキャンバスに変換します。これは私のWindows7セットアップで動作しますが、Windows8 / 10やさまざまなLinuxディストリビューションでも動作するかどうかを確認する価値があります。もしそうなら、問題は解決しました-オフライン開発は通常通り再開します。
画像データをキャンバスに転送したり、JSONデータをフォーム要素に転送したりしようとしても、Chromeがクロスオリジンエラーをスローすることなく、file：// URIから画像とJSONデータを参照できるようになりました。