問題タブ [preflight]

以下のコードは私が実行しているものです。コードスタイルについてはお気軽にどうぞ...私は新しいです：p

あるサーバーの HTML ページから 2 番目のサーバーの API に Ajax GET リクエストを送信しようとしています。私はすでに CORS の山に登って勝ちました (つまり、最初は CORS エラーが発生していましたが、その問題は解決しました)。現在、以下の例外が発生しています。ここに大きな疑問があります：

Swagger を使用してグローバル OPTIONS ハンドラを定義し、Ajax Preflight リクエストに適切に応答する正しい方法は何ですか?

または、私が完全なNoobである場合...私が間違っていることを教えてください。ここでのサポートに本当に感謝しています...これは私を困惑させました.

「HTMLとノードを同じサーバーで実行する必要があります」を断ち切るには。応答... 適切にスケーリングしてセキュリティを確保するには、フロントエンドとは別に API を実行する必要があります。私の場合、フロントエンドはフル スケールの Web アプリケーションであり、API は視覚的な創造性とエンジニアリングの才能を分離するために使用されます。:)

これがシナリオです...

クライアント: 任意の Web サーバー: jQuery 1.6.2 を使用する Amazon Linux AMI 上の Apache コンテンツ: ajax を使用して API への GET または POST 呼び出しを行うフォームを含む単純な html ページ API サーバー: Node Swagger Express を実行する Amazon Linux AMI (に更新現在) 動作: HTML ページを参照します [送信] ボタンをクリックします 例外がコンソールに出力されます

例外：

結果 (Postman によって返される):

ヘッダー (Postman によって返される):

注: 例外のため、API から応答が返されません。

ウェブページコード:

API コード: app.js

ping.js

swagger.yaml

デフォルト.yaml

Spring (4.2.3) で構築された API と AngularJS (1.3.19) で構築されたフロントの 2 つのアプリに分割された webapp があります。2 つのアプリは同じサーバー上にないため、クロス オリジン リクエストに苦労しています。アプリが /articles に対する GET のような単純なリクエストを使用している場合、問題はありません。アプリが JSON 本文の POST /articles などのプリフライト リクエストを使用している場合、POST が可能かどうかを確認する OPTIONS リクエストに 403 があります。

web.xml :

CORSFilter.java :

リクエストヘッダー:

• Access-Control-Request-Headers:accept、コンテンツ タイプ
• Access-Control-Request-Method:POST
• オリジン: http://localhost:9001

応答 ：

• 依頼方法：OPTIONS
• ステータスコード:403 禁止

応答ヘッダー:

• Access-Control-Allow-Headers:accept、コンテンツ タイプ
• アクセス制御許可メソッド:GET、POST、PUT、DELETE、OPTIONS
• Access-Control-Allow-Origin: http://localhost:9001

3 つの Access-Control-Allow-X の値についても * を試しましたが、それでも同じ問題が発生します。Chrome と Firefox でこの問題に直面しています。Safari では 403 が表示されますが、POST は実行されます。

インターネットで見つけたこの問題に対するすべての回答は役に立ちませんでした。OPTIONS リクエストが 403 を返す理由がわかりません。すべての Access Control ヘッダーが正しい値に設定されているようです。

私が数日間直面している問題を解決してくれてありがとう。

[更新] localhost:9000 の AngularJS アプリから localhost:8080 の API に呼び出しを行うと、動作します! しかし、localhost:9000 から Heroku でホストされている API に呼び出しを行うと、そうではありません。Heroku は何かをブロックしていますか?

The title pretty much says it all. I know I can bypass it in my browser with --disable-web-security (for chrome) but how does it work for releasing the app? I have no access to the server that is set to deny reverse proxies and only accepts GET requests not OPTIONS this leads to prefight issues. How can I work around this?

I've taken a look at these but they don't seem to answer the prefight from release workaround. Any Suggestions/workarounds?

http://blog.ionic.io/handling-cors-issues-in-ionic/

https://blog.nraboy.com/2014/08/bypass-cors-errors-testing-apis-locally/

問題:

クロスドメインajax リクエスト (CORS)を介して、基本認証で保護されているページ (securePage.html) を読み込もうとしています。

基本認証 (カスタムヘッダー) + CORS = プリフライト OPTIONS-Request!

認証情報は実際のリクエストに提供されますが、プリフライト リクエストはそれらを送信しません!

応答: 401 Unauthorized!

401 Unauthorized エラーのスナップショット

ル環境:

サーバー: IIS 8.5 は私の securePage.html をホストします。これは私の web.config です。

ローカル PC ( http://localhost:4444 ) から ajax リクエストを送信します。

質問:

どうやら承認ルールは何もしないようです! なんで？私は試した：

成功なし！

この問題の解決策はありますか? ここで何か見逃しましたか？

ル ソリューション:

この質問が漠然としすぎていないことを願っていますが、基本的なことが欠けているように感じます。これが私の状況です。各ユーザーのローカル マシン (Windows 7) で実行されるシック クライアント アプリケーションがあり、アプリケーションとやり取りするための JavaScript API を提供します。サーバーでホストされている Web アプリがありますが、localhost に対して AJAX 要求を行い、シック クライアントの JS API とやり取りします。

1 台のマシンで、Web アプリを読み込みます。localhost に対して行われるすべての AJAX リクエストは、OPTIONS プリフライト リクエストなしで行われます。JS コンソールの [ネット] タブには、作成された POST が表示され、応答が成功しています (必要なすべての CORS ヘッダーを含め、応答に含めるヘッダーをシック クライアントに伝えることができます)。

別のマシンで、同じサーバーから Web アプリを読み込みます。ただし、AJAX 要求が localhost に対して行われると、(予期される) OPTIONS 要求が行われます。残念ながら、シック クライアントは適切な Access-Control-Allow-Origin ヘッダーで応答しないため、その後の POST は実行できません。

ブラウザーは問題ではありません。最新バージョンの Firefox と Chrome をテストしましたが、マシンからは常に同じ動作が得られます。4 台のマシンでテストしました。2 台は OPTION を送信し、2 台は先行する OPTION なしで POST を送信するだけです。AJAX の宛先がオリジンと異なるかどうか、およびプリフライト リクエストを送信するかどうかは、ブラウザ次第のようです。AJAXリクエスト（localhostまたはlvh.meのいずれかへの）がWebページのソースとは異なるホスト/ドメインであるにもかかわらず、私のマシンがOPTIONSリクエストを送信しない理由を一生理解できません、別のマシンから同じページをロードすると、それらが生成されます。

これに影響を与える何らかのブラウザ設定はありますか？それともWindowsの設定？これで異なる動作が見られるのはなぜですか?

更新1:

単純化して明確にするために、machineA と machineB の 2 つのマシンがあります。どちらのマシンも、リモート サーバー example.com から Web アプリを読み込みます。どちらのマシンにも、Web サーバーと API を提供する本格的なシック アプリケーションがローカル マシンにインストールされています。example.com から読み込まれる Web アプリには、AJAX 要求を localhost に送信するための JavaScript コードが含まれているため、各ユーザーはシック クライアント アプリケーションの独自のローカル インスタンスと対話できます。localhost != example.com であるため、リクエストはクロスドメインと見なす必要があります。

machineA が標準の jQuery AJAX リクエストを localhost に送信すると (そのうち、POST のペイロードは単純に「true」であり、これによりシック クライアントは値をエコー バックします。シック クライアントが偶数かどうかを判断するためのポーリングに使用されます)。 POST は OPTIONS リクエストなしで直接行われます: POST http://localhost:4000/cgi-bin/Extensions/GeoLinkConsole/evaljs.html 200 OK 0ms 興味深いことに、その POST からの応答には Access-Control- CORS エラーを回避するために、example.com を含む Allow-Origin ヘッダー。

machineB が example.com から同じページをロードし、同じ「true」ペイロードを使用して同じ標準 jQuery AJAX リクエストを localhost に送信すると、ブラウザは OPTIONS リクエストを送信します。これは、私が実際に期待する動作です。200 OK の OPTIONS 要求応答ですが、Access-Control-Allow-Origin ヘッダーが含まれていないため、POST が通過できません。それは私の主な関心事ではなく、明らかにシック クライアントの問題です。私の最大の疑問は、OPTIONS を生成するマシンと生成しないマシンがある理由です。これが説明に役立つことを願っています。

更新 2:

リクエストヘッダーの両方のセットを含めています。実際のリクエスト ヘッダーが OPTIONS リクエストが生成されるかどうかに影響する可能性があることを知りませんでした。すぐに、OPTIONS を送信しているものには Access-Control-Request-Headers と Access-Control-Request_Method の両方が含まれていて、もう一方には含まれていないことがわかります...

OPTIONS なしで POST を送信するマシンからの要求ヘッダー:

OPTIONS を送信するマシンからの要求ヘッダー:

さらに、マシンには「一般的な」ヘッダー ブロックがあります。投稿したばかりの要求ヘッダーは元の POST 要求用であり、これらはプリフライト OPTIONS 要求に関連していると想定しています。

ここからのサンプルによると：

リクエストが GET、HEAD、または POST 以外のメソッドを使用する場合。また、POST を使用して、application/x-www-form-urlencoded、multipart/form-data、または text/plain 以外の Content-Type を持つリクエスト データを送信する場合 (たとえば、POST リクエストが XML ペイロードをサーバーに送信する場合) application/xml または text/xml を使用すると、リクエストはプリフライトされます。

したがって、次の例では、XML Content-Type とカスタム ヘッダーにより、プリフライトが実行されますX-PINGOTHER。

しかし、いわゆるプリフライト OPTIONS リクエスト (以下) では、サーバーは HTTP メソッドとカスタム ヘッダーのみを通知されます。誰もサーバーに について話しませんでしたXML Content-Type。

論理的には、プリフライト リクエストが送信される限り、Content-Typeがプリフライトを必要としない 3 つの形式ではないことを意味します。しかし、他にも多くの可能性があります。肝心なのは、サーバーはプリフライト要求が送信された理由を認識できる必要があるということです。

では、パズルのピース (コンテンツ タイプ) が欠けている状態で、サーバーがこの要求を許可するかどうかを合理的に決定するにはどうすればよいでしょうか?