Share via


ACS または Facebook とのフェデレーション使用時に発生する空白の応答ページのトラブルシューティング

原文の記事の投稿日: 2011 年 7 月 12 日 (火曜日)

さまざまなフェデレーション シナリオを試している間に、掲題の問題が起きたことが数回ありました。いずれのケースも、Facebook をログインの oAuth ソースとして使用するか、Azure の AppFabric ACS をフェデレーション ID プロバイダーとして使用したときに見られた現象です。共通するのは、何かをブラウザーを介して対話式に操作していたり、プログラムによって ACS への POST を実行して操作していたことです。いずれの場合も応答でエラーが返されますが、エラー メッセージは要領を得ません。たとえば、Facebook の oAuth 機能を使用すると、Facebook のログイン サイトにリダイレクトされ、そこで資格情報を入力した後で元のアプリケーションにリダイレクトされて戻ります。しかし、この過程で問題が起きると、たいていの場合にブラウザーから HTTP エラー 400 が通知され、サーバーがエラーになります。同じ現象は、プログラムによって ACS に POST した場合にも見られます。この操作で問題が起きると、高い確率で HTTP エラー 400 が返され、ページが見つからないことを意味する "page not found" やそれに似た意味のエラー メッセージが表示されます。このメッセージが問題の解決に役立つでしょうか。何の参考にもなりません。

悲しいことに、このようなページが表示されたときに取りうる最善の対処は、Fiddler (www.fiddler2.com (英語)) を使うことです。Fiddler を使用すると、ブラウザーには決して表示されない詳細な応答情報を見ることができます。たとえば、ACS 使用時の問題を Fiddler で確認すると、POST メッセージの形式に誤りがあることを示す情報が応答に含まれていました。これは、"page not found" のような、解決の糸口にならないメッセージよりもはるかに有益な情報に違いありません。また、Facebook のケースでも、リダイレクトで戻ろうとした URI が無効であったり、信頼されないものであることが Fiddler の応答から判明しました。これも 400 エラーとか、要求が無効だったことを意味する "bad request" を示すだけのメッセージよりも、ずっと役に立つことは明らかです。

つまり、ここで説明したような明らかな手詰まりに陥ったときは、Fiddler を起動し、詳細な応答情報を参照して、問題解決につながる有益な情報を見つけることをお勧めします。 

これはローカライズされたブログ投稿です。原文の記事は、「Troubleshooting Blank Response Pages When Using Federation with ACS and Facebook」をご覧ください。