問題タブ [preflight]

場合によっては、ブラウザがプリフライト HTTP リクエストを行うことをご存知かもしれません: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests

私の Web アプリケーションはまだ Symfony1 にあります。RESTful サービスを実装したいので、Symfony ルーティングを使用して GET や POST などの特定の HTTP リクエスト メソッドを許可します ( http://symfony.com/legacy/doc/reference/1_4/en/10-Routing#chapter_10_sub_sf_method )。

例：

OPTIONS リクエストは sf_method 値として定義/処理できないようです。私の考えが正しいかどうかの情報が見つからなかったので、私が正しいかどうか、または私が見つけられなかった解決策もあるのだろうかと思っています。

前もって感謝します！

非常に単純な CORS フィルターを持つ Spring Boot REST アプリケーションがあります。私がやりたいことは、特定のリストを提供するのではなく、Access-Control-Request-Headers ヘッダーの値に動的に応答することです。一般的な知恵は、「Access-Control-Allow-Headers」で返される値を明示的に設定することのようですが、オリジンのセットをホワイトリストに登録し、オリジンが送信するすべてのヘッダーを許可したいと考えています。Access-Control-Request-Headers の Access-Control-Allow-Headers の値をオウム返しする方法が見つかりません。

これがコードです

このリクエストと Chrome からのレスポンス (Access-Control-Allow-Headers の値をハードコーディングしたとき)

これがエラーです

XMLHttpRequest はhttps://myapp.com/gradebooks/5566669e-e4b0-d05e-0150-98d7ffffffff/assignments/3ad7f1e7-679b-4d8b-856e-d2e3589eaad6を読み込めません 。要求ヘッダー フィールド Content-Type は、Access-Control-Allow-Headers では許可されていません。

フィルターへのデバッグで見つかったのは、フィルターに到達するまでに Access-Control-Request-Headers とそのヘッダーのみが欠落していることです。ヘッダーのスペルを間違えて到着するため、何かがヘッダーを傍受し、フィルターに到達する前に破棄しているようです...

クロス ドメイン リクエストをサポートする REST API を実装しています。CORSを使用して、これを達成したいと考えています。ほとんどすべてのリクエストは「単純ではない」ものです。つまり、すべての非 GET リクエストに対して、ブラウザからプリフライト リクエストを送信する必要があります。

プリフライト/OPTIONS リクエストの量を制限するために、ブラウザーに OPTIONS リクエストをキャッシュさせようとしています。これは Firefox と Safari では機能するようですが、Chrome では機能しません。Chrome がプリフライト リクエストを 10 分間しかキャッシュしないことはわかっていますが、私の場合はキャッシュがまったく行われないようです。

Chrome で送受信される HTTP リクエストとレスポンスは次のとおりです。

リクエスト：

応答：

WebApi を MVC6 にアップグレードしています。

WebApi では、すべての HTTP リクエストをインターセプトでき、それがプリフライトの場合は、ブラウザーが受け入れるヘッダーで応答できました。

MVC6 WebApi で同じことを行う方法を理解しようとしています。

これが WebApi コードです。

MVC6 で同じことを行うにはどうすればよいですか?

ありがとう、ボブ

フィードバックに基づく次の試みは次のとおりです。ミドルウェアのパイプラインを理解していれば、おそらく自分でこれを理解できたでしょう。もちろん今から学びます。

このコードを試してみましたが、期待どおりに http リクエストにヒットしませんでした。

私のAngularアプリが新しいMVC6 Web Apiと通信できるように、CORSを有効にしようとしています。

CORSプリフライトが最初に送信されるため、「GET」は機能しますが、「POST」は機能しません。IIS はこのプリフライトをインターセプトして応答します。

WebApi2 では、次の web.config 設定を使用して、IIS がプリフライトを傍受するのを防ぐことができました。

次に、リクエストを調べて、「OPTIONS」に必要なヘッダーを返すことができました。

新しい MVC6 WebApi でこれらの両方を実行できますが、何らかの理由で IIS に「OPTIONS」プリフライトのインターセプトを停止させることができません。

私は MVC でこのコードを使用していますが、IIS に "OPTIONS" 要求のインターセプトを停止させることしかできない場合にのみ機能すると思います。

誰かがこれに対処したり、CORS が動作する MVC6 の実例を持っていますか?

ありがとう

CORS POST リクエストをサーバーに送信しようとしています。

Chrome では、これは期待どおりに機能します。OPTIONS プリフライト リクエストがサーバーに送信され、サーバーがアクセス コントロール ヘッダーで応答し、POST リクエストが送信されます。IE または Firefox でこれを実行しようとすると、OPTIONS 要求でリファラーが送信されないため、access-control-allow-origin ヘッダーを追加できません (これはプログラムで行われるため)。

Javascript は次のとおりです。

Chrome のヘッダーは次のとおりです。

Firefox のヘッダーは次のとおりです。

リファラーが OPTIONS プリフライト リクエストで送信されることを保証する方法はありますか? そうでない場合 - 参照元の URL を取得して allow origin ヘッダーを追加できる別の方法はありますか?

別のドメインから CouchDB に接続するアプリケーション内からユーザーのパスワードを変更しようとしています。私のコードは、 CouchDB Docsの例とほぼ同じです。つまり、ドキュメントを取得し、データを変更してから、変更とともに PUT リクエストを送信します。この問題は PUT リクエストで発生しています。CORS のため、ブラウザーは PUT リクエストを送信する前に OPTIONS リクエストを実行しようとしますが、OPTIONS リクエストは 405 Method Not Allowed を返します。

これを回避する方法を知っている人はいますか？

役立つ場合のリクエストヘッダーは次のとおりです。