問題タブ [preflight]

私はウェブアプリケーションを開発しています。基本認証を使用しています。OPTIONS リクエストを処理する必要があります。これらは、Web ブラウザのプリフライト リクエストと、WebDAV クライアントからの機能サポート リクエストです。

OPTIONS リクエストは認証を要求せずに処理する必要があることを理解している限り (つまり、私のサーバーは 401 Unauthorized で応答するべきではありません)、次のような応答を返す必要があります。

私の質問は、URL に関係なく、OPTIONS 要求に対して常に同じ応答を提供する必要があるか、または URL に依存する必要があるかです。

たとえば、上記の例の file.ext が見つからない場合、「404 Not found」または「200 OK」で応答する必要がありますか?

API プロキシを作成し、「API のダイレクト ブラウザー アクセスを有効にする — CORS を介したブラウザーからのダイレクト リクエストを許可する」というボックスをオンにします。しかし、私の OPTIONS リクエストはまだ失敗しています:

CORSプリフライトオプションリクエストについて私が理解していることから、クライアントは最初にOPTIONSリクエストをサーバーに送信し、「安全な」CORSを保護します。このリクエストは、利用可能なリクエスト タイプのリストを含むレスポンスを返す必要があります。

私の質問: Apigee が OPTIONS リクエストに正しく応答し、プロキシの背後にある API に OPTIONS リクエストを渡さないようにするにはどうすればよいですか? . それが役立つ場合、AngularJS JavaScript アプリが Apigee エンドポイントと通信しようとしています。

Javascript エラー:

デフォルトの「CORS の追加」xml

デフォルトのプロキシ エンドポイント xml

デフォルトのターゲット エンドポイント xml

jquery-fileupload を使用して、ユーザーがファイルを外部サービスにアップロードできるようにしています (具体的には Cloudinary です)。

これは外部ターゲットであるため、ブラウザーは CORS 要求を開始します。ただし、ブラウザーが CORS プリフライト リクエストを先頭に追加していることに気付きました。 http://www.html5rocks.com/en/tutorials/cors/は、プリフライト リクエストがいつトリガーされ、いつトリガーされないかについて、非常に優れた洞察を提供します。私の知る限り、私のリクエストは CORS の単純なリクエストであるというすべての基準を満たしています (セクション「CORS リクエストのタイプ」を参照)。

外部サービスに送信されるファイルアップロード リクエスト:

ファイル アップロード リクエストの前に外部サービスに送信される追加のプリフライトリクエスト:

この余分なプリフライト リクエストを回避する方法はありますか? 私が見る限り、ファイル アップロード リクエストは、Content-Type multipart/form-data と単純なリクエスト HTTP ヘッダーのみを含む HTTP POST であるため、CORS の単純なリクエストです。

余分なプリフライト リクエストを削除したい理由は、Cloudinary がファイル アップロードへの応答として HTTP 302/304 リダイレクトを送信するためです。ブラウザはこれらのリダイレクトに従いません。Chrome は次のメッセージで失敗します。

CORS リクエストの仕様を読んでいたところ、プリフライト リクエストについて次のことがわかりました。

これらは、プリフライト結果キャッシュ エントリまたはプリフライト リクエストのいずれかを使用して最初に認証する必要がある GET 以外の HTTP リクエスト メソッドを使用した、同一でないオリジン URL へのリクエストです。

プリフライト リクエストの目的は、サーバーの状態が (不当に) 変更された場合に備えて、リクエストを行う前に許可されているかどうかを確認することだと考えていました。

ただし、HEAD と OPTIONS はサーバーの状態を変更しません。プリフライト チェックの理由を誤解しているに違いありません。

GET ではなく HEAD と OPTIONS のプリフライト チェックを行う目的 (別名、理由、動機、または理論的根拠) は何ですか? GET の特別な点は何ですか?

サーバー上の IIS から単純な GWT アプリケーションを実行しています。同じサーバーで実行されている tomcat への HTTP リクエストをテストしようとしています。ただし、両方のアプリケーション サーバーが異なるポートで実行されているため、私のブラウザー (chrome と firefox) は要求を CORS 要求として扱います。

Tomcat が CORS リクエストを受け入れられるようにするために、Tomcat 7.0.52 に更新し、グローバルな web.xml 構成で CORS フィルターを有効にしました。この簡単なセットアップをテストしましたが、うまくいくようです。GWT のコードは次のとおりです。

これに関連付けられている CORS フィルターは次のとおりです。

このセットアップでは、Tomcat から 200 OK 応答を受け取ります。したがって、CORS フィルターが機能していると想定しても安全です。これを裏付けるために、フィドラー トレースを行ったところ、すべて問題ないように見えました。

tomcat(solr)のアプリにアクセスしたいので、CORSリクエストでベーシック認証が必要です。これにより、プリフライト リクエストが明確になります。資格情報の使用を有効にするように CORS フィルターをセットアップしたので、変更する必要はありませんでした。だから、私は自分のコードに次の変更を加えました

ここで、このコードを使用しようとすると、onResponseReceivedコード ブロック内に入り、値が「0」のアラート ボックスが表示されます。フィドラー トレースを取得すると、次のようになります。

カスタム ヘッダーをリクエストに追加しているので、ブラウザがプリフライト リクエストを送信するのは理にかなっています。しかし、CORS フィルター構成に認証ヘッダーを追加しているにもかかわらず、Tomcat が 401 コードで応答する理由がわかりません。

助けや反応をいただければ幸いです

編集:もう 1 つ気づいたこと - 私の URL が単に "bavarians:8080/solr/" の場合、Tomcat はプリフライトされたリクエストを正常に承認し、すぐ次のリクエストは通常​​の GET リクエストとして 200 OK レスポンスで処理されます。しかし、関数名を入力して URL でクエリを実行すると、再び 401 が返されます。ブラウザから上記の URL にアクセスするには、Basic 認証が必要です。ある時点CORSFilterまでは機能します

私は、現在モバイル Web サイトに変換されている PhoneGap アプリを開発しました。1 つの小さな不具合を除けば、すべてがスムーズに動作します。POST リクエストを介して特定のサードパーティ API を使用しています。これはアプリでは正常に動作しますが、モバイル Web サイト バージョンでは失敗します。

よく見ると、AngularJS (実際にはブラウザーだと思います) が最初に OPTIONS リクエストを送信しているようです。今日、CORS について多くのことを学びましたが、CORS を完全に無効にする方法がわかりません。私はその API にアクセスできません (そのため、その側での変更は不可能です) が、彼らは私が取り組んでいるドメインを Access-Control-Allow-Origin ヘッダーに追加しました。

これは私が話しているコードです：

ブラウザ (または AngularJS) がその OPTIONS リクエストを送信するのを防ぎ、実際の POST リクエストにスキップするにはどうすればよいですか? AngularJS 1.2.0 を使用しています。

前もって感謝します。

だから私は Go でこの RESTful バックエンドを書いています。これは、クロスサイト HTTP リクエストで呼び出されます。つまり、別のサイトによって提供されるコンテンツから呼び出されます (実際には、別のポートですが、同じオリジン ポリシーが適用されます)。 .

このシナリオでは、ユーザー エージェントは場合によっては、プリフライト OPTIONS リクエストを送信して、実際のリクエストが安全に送信できるかどうかを確認します。

私の質問は、Go コンテキストでこれらのプリフライト リクエストをどのように処理し、適切に応答するかということです。私が思いついた方法はあまりエレガントではありません。私が思いもよらなかった方法が他にあるのではないかと考えています。

標準net/httpパッケージを使用すると、おそらく次のように、ハンドラー func でリクエスト メソッドを確認できます。

また、 Gorilla の パッケージを使用muxして、関連する URL パスごとにプリフライトの「OPTIONS」ハンドラーを登録することもできます。

おそらく、この質問に対する答えは単純です:うん、それらはあなたの基本的なオプションです. しかし、私が気付いていないベストプラクティスがいくつかあるのではないかと思いました。