フェッチ リクエストが「クロスオリジン リクエストがブロックされました」エラーで失敗するのはなぜですか? CORS を使用して修正するにはどうすればよいですか?

クロスオリジンリクエストがブロックされました: CORS とフェッチ構文を理解する

ブラウザがスクリプトのアクセスを妨げるクロスオリジンリクエストの領域セキュリティ上の理由から、さまざまな起源のリソースを使用しているため、開発者はしばしば恐ろしい「いいえ」に遭遇します。 「要求されたリソースに「Access-Control-Allow-Origin」ヘッダーが存在します」というエラーが発生します。この問題を解決するには、CORS (Cross-Origin Resource Sharing) の概念とそのフェッチ構文への影響を理解することが不可欠です。

CORS の難問

CORSは、他の Web サイトで実行されている悪意のあるコードからユーザーがローカルに保存されている機密情報にアクセスできないようにする、ブラウザーによって強化されるメカニズムです。デフォルトでは、ブラウザーは JavaScript コードからのクロスオリジン要求を禁止しますが、サーバーからの応答に Access-Control-Allow-Origin ヘッダーを追加することで、この制限を緩和する方法を提供します。このヘッダーは、リソースへのアクセスを許可するオリジンを指定します。

構文エラーの解読

指定されたコード スニペットで、開発者はモード 'no の使用を試みます。 CORS を無効にするには、Fetch オブジェクトの -cors 属性を使用します。ただし、mode: 'no-cors' はブラウザーに応答ヘッダーと本文へのアクセスをブロックするよう効果的に指示するため、このアプローチには根本的な欠陥があります。したがって、サーバーが適切な Access-Control-Allow-Origin ヘッダーを含む応答を送信したとしても、それはブラウザーによって無視され、フェッチ呼び出しで構文エラーが発生します。

モード: 'no-cors'

の落とし穴 モード: 'no-cors' の使用は、一般的には使用できません。ブラウザによる応答の処理に予期せぬ制限が生じる可能性があるため、推奨されます。具体的には、このモードは、JavaScript コードでデータを適切に処理するために必要なことが多い、応答の内容とヘッダーをブラウザーが公開するのをブロックします。

プロキシ ソリューション

ブラウザのセキュリティを損なうことなく CORS 制限を回避するには、CORS プロキシを使用できます。プロキシは仲介者として機能し、クライアントに代わってリクエストをクロスオリジンにし、元のリクエスタに返す前に必要な CORS ヘッダーを応答に追加します。

ポストマンとブラウザ

人気の HTTP リクエスト テスト ツールである Postman は、デフォルトでは CORS 制限を強制しないことに注意することが重要です。 する。この違いは、Postman が API エンドポイントのテストを目的としたデバッグ ツールであるのに対し、ブラウザはユーザーのセキュリティを優先するという事実に由来します。

概要

結論として、モード: 'no-cors' は、不透明な応答が必要な限られた状況でのみ使用する必要があります。 CORS プロキシは、ブラウザのセキュリティを維持しながら、クロスオリジン リクエストに対する価値のあるソリューションを提供します。 Web サイトとそのリソース間の安全かつシームレスな通信を可能にするためには、CORS の複雑さを理解し、適切な技術を適用することが不可欠です。

以上がフェッチ リクエストが「クロスオリジン リクエストがブロックされました」エラーで失敗するのはなぜですか? CORS を使用して修正するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。