クロスドメインの問題の解決: 要求されたリソースに「Access-Control-Allow-Origin」ヘッダーが存在しません。

目次

エラーメッセージ

原因分析

簡単なリクエスト

単純な要求ではない

プリフライトリクエスト

要求応答


エラーメッセージ

まず、ブラウザ コンソールからのエラー メッセージを見てみましょう。

CORS レスポンス ヘッダー値が有効であることを確認してください
リクエストまたは関連するプリフライト リクエストのレスポンス ヘッダーが無効または欠落しているため、クロスオリジン リソース共有 (CORS) リクエストはブロックされました。< /span>不透明な応答で十分な場合は、要求のモードを no-cors に設定して、CORS を無効にしてリソースをフェッチできます。この方法では CORS ヘッダーは必要ありませんが、応答コンテンツにはアクセスできません (不透明)。
この問題を解決するには、CORS リクエストへの応答や関連するプリフライト リクエストにヘッダーが欠落していないことを確認し、有効なヘッダー値を使用します。

エラーメッセージの翻訳:

有効な CORS レスポンス ヘッダー値を確認する
このリクエストまたは関連するプリフライト リクエストのレスポンス ヘッダーが無効か欠落しているため、クロスオリジン リソース共有 (CORS) リクエストはブロックされました。 . .
この問題を解決するには、CORS リクエストや関連するプリフライト リクエストへの応答にヘッダーが欠落しておらず、有効なヘッダー値を使用していることを確認します。
不透明な応答で十分な場合は、リクエストのモードを no cors に設定して、cors を無効にしてリソースを取得できます。この方法では CORS ヘッダーは必要ありませんが、応答の内容はアクセスできません (不透明)。 

原因分析

エラー メッセージには「CORS レスポンス ヘッダー値が有効であることを確認してください」と記載されていますが、CORS についてはどうですか?

CORS、正式名は Cross-Origin Resource Sharing で、現在のドメイン (ドメイン) 内のリソース (html/js/web サービスなど) を共有できるようにします。他のドメイン (ドメイン)。スクリプト リクエスト アクセスのメカニズム。通常、同一オリジン セキュリティ ポリシー (同一オリジン セキュリティ ポリシー) により、ブラウザはそのようなクロスドメイン リクエストを禁止します。 a>

は、CORS 応答ヘッダー値が欠落しているか、CORS 応答ヘッダー値が無効であることを意味します。次に、この応答ヘッダーの問題を探し始める必要があります。まず、CORS 応答ヘッダー値が存在する理由を説明しましょう。エラー メッセージからわかるように「CORS ヘッダーは必要ありませんが、応答コンテンツにアクセスできません (不透明)」 これは必要ですが、それ以外の場合はたとえ結果が正常に応答されたとしても、アクセスすることはできません。

簡単なリクエスト

ブラウザは CORS リクエストを直接発行し、Origin フィールドをリクエスト ヘッダーに追加して、リクエストがどの フィールドであるかを示します。 /span>。返されるステータス コードは 200 OK となるため、このエラーはステータス コードから特定できません。 「要求されたリソースに "Access-Control-Allow-Origin" ヘッダーが存在しません。」 フィールドを見つけられない場合、リクエストが許可範囲内にないことを意味し、ブラウザ コンソールにエラーが表示されます。Access-Control-Allow-Origin の場合、サーバーはこの値を使用してリクエストを受け入れるかどうかを決定します。ブラウザが応答ヘッダーにソース (リクエスト プロトコル + ホスト名 + ポート番号)

実際、サーバーはリクエストの結果を返しますが、ブラウザは結果の受け入れを拒否します。

これでAccess-Control-Allow-Originこのフィールドは非常に重要です。このフィールドの値はリクエスト時の値です フィールドの値を指定すると、リクエストされた結果がブラウザで正常に受け入れられます。 Origin

Access-Control-Allow-Origin フィールドの値は、任意のオリジンからのリクエストが受け入れられることを示す * に設定できます。

単純な要求ではない

単純でないリクエストとは、POST リクエストや PUT リクエストなど、サーバーに特別な要件があるリクエスト、または Content-Type フィールドが application/json であるリクエストを指します。

プリフライトリクエスト

単純でない CORS リクエストの場合、正式なリクエストの前にプリフライト リクエストが開始されます。

つまり、ブラウザはまずサーバーがソースからのリクエストを受け入れるかどうかを確認し、サーバーが同意した後にのみ正式なリクエストを発行します。

プリフライト リクエストのリクエスト メソッドはOPTIONSで、リクエスト ヘッダーには Origin が含まれます。 > フィールド。どのソースからのものかを示します。さらに、プリフライト リクエストには Access-Control-Request-Method フィールドも必要です。このフィールドは、ブラウザが要求するリクエストのタイプを示すために使用されます。次の問題; Access-Control-Request-Method a> フィールドは、ブラウザが CORS リクエストで送信する追加のリクエスト ヘッダー フィールドを指定するために使用されます。 Access-Control-Allow-Headers

要求応答

このため、サーバーはプリフライト リクエストに応じてブラウザに望ましい結果を提供する必要があります。そうでない場合、ブラウザはサーバーに正式なリクエストを行いません。

バックエンドは、次のようにフィルターまたはインターセプターに応答ヘッダーを設定できます。

response.setHeader("Access-control-Allow-Origin", request.getHeader("Origin"));
response.setHeader("Access-Control-Allow-Methods", "GET,POST,OPTIONS,PUT,DELETE,PATCH");
response.setHeader("Access-Control-Allow-Headers", request.getHeader("Access-Control-Request-Headers"));

プリフライト リクエストが通過した後、ブラウザによって送信される正式なリクエストは単純なリクエストと同じになります。ブラウザはリクエスト ヘッダーに Origin フィールドを追加し、サーバーはレスポンス ヘッダーに Access- を追加します。 . Control-Allow-Originフィールド。

おすすめ

転載: blog.csdn.net/qq_74312711/article/details/134908533