16

バックグラウンド

（CORSに精通している場合は、最後の質問にスキップできます）

CORS [1]は、ブラウザがさまざまなドメインからのリソースへのアクセスを許可できるようにするソリューションです。たとえば、AJAXを使用したRESTデータバックエンド。

Chrome（およびWebkitの友達）がHTTP認証プロンプトを処理しないことは、そのようなリソースが要求するときにインターネット上でよく観察されています。例[2]（これは、たとえば、画像タグの読み込みが401で失敗し、資格情報が必要な場合に、Webメールのサインインページでブラウザが認証ログインダイアログを表示しないようにするためです。ウェブメールの資格情報）

この状況でのChromeの動作は、応答をドロップし、ほとんどサイレントにリクエストをキャンセルすることです。

実際、Chromeは200が発生した場合にのみ通常どおり応答を許可します。その他のステータスコードはすべて飲み込まれ、AJAX呼び出しは中止されます。

jQueryを使用してAjaxリクエストを実行し、リモートサイトがHTTP 401ステータスコードで応答した場合、リクエストはキャンセルされ、ajaxはエラーで完了しますが、401コードがありません。接続が切断されたか、同等の下位層の問題であるかのように見えます。

このCORSの警告について具体的に言及している、私が見た唯一のWebサイトは[1]です。

閲覧者は、エラーが発生したときに何がうまくいかなかったかを報告するという良い仕事をしていません。たとえば、Firefoxはすべてのエラーについてステータス0と空のstatusTextを報告します。ブラウザもコンソールログにエラーメッセージを報告しますが、JavaScriptからこのメッセージにアクセスすることはできません。onerrorを処理すると、エラーが発生したことがわかりますが、それ以外はあまりありません。

chrome起動フラグを使用してこのセキュリティを無効にすることができます-バックエンドが「正常に」機能していることと、適切なステータスコードの損失によって1つの健全性が過度に影響を受けていないことの両方をテストするためだけです。[2]を参照してください

問題

バックエンドとフロントエンドのクライアントコードが認証プロセスの一部として401を使用することになっている場合はどうなりますか？-障害はすべて、1つの「エラー」出力にまとめられます。

例：認証要求を発行すると（たとえば、2本足のOAuthトークン要求-RESTfulバックエンドに対して-適切なステータスコードを使用します-クライアントは次のことを認識しません。

  • 401ユーザーが認証されていません。
  • ---接続に失敗しました。
  • 400悪いリクエストがありました。
  • 500サーバーに問題があります。
  • 207成功した後は内容がありませんでした。

当時費用対効果が高いと見なされたのと同じくらい多くのベストプラクティスに従って、非常にRESTfulに作成されたバックエンド。これらの1つは、適切なHTTPステータスコードに依存していました。私たちが取り組んでいるJavaRESTクライアントはうまく機能しました。

今、私はWebページに埋め込むためのJavascriptクライアントの作成を開始しました-特にCORSを使用して、Chromeなどで問題が発生しました（Firefoxは問題ないようで、現在はIEを気にしません）。

質問

これらの問題を回避するために人々は何をしましたか？
CORSを信頼できるバックエンドにより適したものにするためにできることはありますか？

リンク

  1. CORSチュートリアル：http ：//www.html5rocks.com/en/tutorials/cors/
  2. Chromeは、リソースに対して401トリガーの認証プロンプトを許可しません：http ：//code.google.com/p/chromium/issues/detail？id = 81251
  3. --disable-web-security for Chrome：Chromeで同一生成元ポリシーを無効にします
4

3 に答える 3

6

この問題が発生しました。401応答のHTTPヘッダーを設定することで、私はうまくいきました。私が使用していたライブラリは、カスタマイズなしではこれを適切に実行していませんでした。例えば：

  self.headers["Access-Control-Max-Age"] = '1728000'
  self.headers["Access-Control-Allow-Origin"] = "http://localhost:3001"
  self.headers["Access-Control-Allow-Methods"] = "ANY"
  self.headers["Access-Control-Allow-Credentials"] = 'true'
于 2013-07-17T13:22:40.273 に答える
1

今日は、Chromeでウェブアプリを開発している間、これに対する答えを探すために数時間を費やしています。他の何人かは、この状況のかなり詳細な分析を書いています。

2つの潜在的な問題がありました：

  1. Chromeがプリフライトを実行していて、それに応じて200以外またはCORS以外の応答を受け取っていた可能性があります

  2. 何らかの理由で、200以外の（エラー）ステータスコードにヘッダーが添付されていませんでした。この投稿でわかったように、この2番目の理由が問題でした。基本的に、NGINXはデフォルトで成功した応答にのみヘッダーを追加します。CORSを介してエラー応答を取得するには、変更するだけで十分です

add_header 'Access-Control-Allow-Origin' '*';

に

add_header 'Access-Control-Allow-Origin' '*' always;

always記事に記載されているように、とを追加する必要がある場合もあり'Access-Control-Allow-Credentials'ます'Access-Control-Allow-Headers'。これを行った後、すべてのエラーコードもCORSの問題なしで通過しました。APIサービスに使用しているプログラムが同じことをしている可能性があります。これが誰かの時間を助け、節約することを願っています！

于 2020-09-08T07:13:19.660 に答える
-3

何度もいじった後、私はなんとかそれを機能させることができました。赤面

CORSが各ブラウザで機能することを保証する正確なシナリオを構成する非常に多くのブードゥーがあるようですが、次のような多くの問題をさかのぼります。

  • Nginxは、デフォルトでは、デフォルトでリバースプロキシでHTTP/1.0のみを使用します
  • Tomcatは同じキーを持つ重複したinit-param宣言を黙って無視しますが、jettyはそれらを結合し（したがって、CORSフィルターはサーバーではオフでしたがdev-laptopではオンでした）、nginxはいくつかのヘッダーを上書きしていました。

完全にノーゴーと思われるものに出くわしたので、問題を解決するために、jqueryプラグインとしてCORS4xx->200ラッパーを作成することになりました。そのプラグインをデバッグすることで、最終的な修正につながりました。

于 2012-10-01T23:19:07.213 に答える