フォーム認証をトラブルシューティングします。

ASP .NET サポート音声列

フォーム認証のトラブルシューティング

お客様のニーズには、この列をカスタマイズするには、サポート技術情報とサポート音声列にして表示する問題に関心のあるトピックに関するアイデアが将来的にアドレスを送信することを招待します。アイデアとそれの要求フォームを使用してフィードバックを送信できます。この列の下部にあるフォームへのリンクもあります。
ASP.NET サポート音声列へようこそ!Jerry Orman は、自分の名前です。5 年以上にわたって Microsoft とされているし、Microsoft FrontPage などの Web 関連の技術と新しい Microsoft SharePoint テクノロジに重点を置いた時間のほとんどを費やしてきました。サポート エンジニアは、Microsoft ASP.NET を使用する最後の年を費やしてきました。[サポート音声列では、今月で Microsoft ASP.NET フォーム認証をトラブルシューティングする方法について説明しましょう。

フォーム認証のトラブルシューティング

ASP.NET アプリケーションでフォーム認証を使用するとき、ユーザーはログイン ページにランダムにリダイレクトするときに発生する問題をトラブルシューティングする必要するがあります。理想の世界でこの問題発生できる方法で簡単に、デバッガーをアタッチし、問題をキャプチャします。本番環境でただし、これは、ほとんど場合。このようなランダムな問題のトラブルシューティング、根本的な原因を特定できるように、問題に関連する情報をログに記録する必要があります。

このコラムで簡単にここのフォーム認証の概念。クリックするシナリオは、ログイン ページにリダイレクトされているユーザーに潜在顧客との問題を分離することに関連するデータをキャプチャする方法を見てみましょう。フォーム認証情報をログに記録するのには、IHttpModule インターフェイスを実装する方法についても取り上げてみましょう。

フォーム認証の概要

フォーム認証を使用して Web サイトにユーザーが認証すると、サーバーは cookie を作成します。暗号化されたフォーム認証チケットを cookie の値には。サーバーに、アプリケーションへの各要求に cookie が渡されると、 FormsAuthenticationModuleクラスは、cookie の値を復号化し、ユーザーが有効かどうかを決定します。

既定では、 FormsAuthenticationModuleクラスは、Machine.config ファイルに追加されます。FormsAuthenticationModuleクラスがありますプロセスを管理します。

Machine.config ファイルからエントリを次に示します。
<httpModule>     …other modules…
<add name="FormsAuthentication"
type="System.Web.Security.FormsAuthenticationModule" />
…other modules…
</httpModule>

フォーム認証を使用して認証するための一般的な HTTP トラフィックは、次のようになります。
  1. クライアントは、HTTP GET を送信 Default.aspx にします。フォーム認証 cookie は送信されません。
  2. Login.aspx 302 応答 (リダイレクト) をサーバーに送信します。
  3. クライアントは、HTTP POST を Login.aspx に送信します。ログイン情報が含まれています。
  4. Default.aspx に 302 応答 (リダイレクト) をサーバーに送信します。フォーム認証 cookie が含まれています。
  5. クライアントは、HTTP GET を送信 Default.aspx にします。これには、フォーム認証 cookie が含まれます。
実装して、フォーム認証を使用する方法の詳細については、次の MSDN Web サイトを参照してください。フォーム認証 cookie を共有する方法の詳細については、次の ASP.NET Web サイトを参照してください。

ユーザーをログイン ページにリダイレクトされる場合があることの理由

フォーム認証 cookie が失われます。

シナリオ 1

このシナリオでは、ユーザーが Web サイトにログオンします。いくつかの時点では、クライアントがサーバーに要求を送信し、
FormsAuthenticationModuleクラスでは、cookie を受信しません。かどうかユーザーの要求はありません、cookie で Microsoft インターネット インフォメーション サービス (IIS) のログを記録する cookie を有効にすることによって確認できます。そのためには、以下の手順を実行します。
  1. IIS Microsoft 管理コンソール (MMC) を開きます。
  2. Web サイトを右クリックし、をクリックしてください
    プロパティです。
  3. Web サイト] タブをクリックし、[ログ収集を有効にする] をクリックします。
  4. ログの形式がW3C 拡張ログ ファイル形式であることを確認してください。
  5. [プロパティ] をクリックします。
  6. [詳細設定] タブをクリックし、クリックしてください
    プロパティを拡張します。
  7. [拡張プロパティ]、[ Cookie(cs(Cookie)) ] チェック ボックスを選択する] をクリックし、 Referer (cs(Referer))チェック ボックスをオンします。
この問題が発生した後は、クライアントには、問題とそのクライアントの IP アドレスを決定します。そのクライアントの IP アドレスでは、IIS のログをフィルター処理し、<クッキー>] 列を参照します。

注: Log Parser を使用すると、IIS のログを解析します。ログ パーサーをダウンロードするには、次のマイクロソフト Web サイトを参照してください。その特定のユーザーからの要求のリストがある場合は後、は、ログイン ページへの要求を検索します。理解して、このページにリダイレクトされたことと、リダイレクトが発生する前に要求を表示します。何かを表示する場合、クライアントは、次のようないずれかを送信しませんでした、cookie またはクライアントとサーバー間のネットワーク上に cookie が削除されました。

これは、最初のログインです。
メソッドページ応答Cookie
取得/Default.aspx302 (リダイレクト)Cookie はありません。
取得/Login.aspx200 (成功)Cookie はありません。
投稿/Login.aspx302 (リダイレクト)Cookie はありません。
取得/Default.aspx200 (成功).ASPXAUTH
取得/SomePage.aspx302 (リダイレクト)違います。ASPXAUTH クッキー
なしで、サイトでのページに続く要求、その他の要求は、これらのです。ASPXAUTH cookie です。
メソッドページ応答Cookie
取得/SomePage.aspx302 (リダイレクト)違います。ASPXAUTH クッキー
取得/Login.aspx200 (成功)違います。ASPXAUTH クッキー
投稿/Login.aspx302 (リダイレクト)違います。ASPXAUTH クッキー
取得/SomePage.aspx200 (成功).ASPXAUTH

注: そのユーザーからの最初の要求は、フォーム認証 cookie を永続的な cookie を作成する場合を除き、可能性ではありません。IIS のログのみが表示されます、要求で受信した cookie。フォーム認証 cookie を使用して最初の要求に成功したログイン試行した後、要求になります。
シナリオ 2

クライアントの cookie の制限を超えた場合も、フォーム認証 cookie が失われることができます。Microsoft Internet Explorer では、20 までの cookie の制限があります。20 の cookie がクライアント上で作成されると、既存の cookie は、クライアントのコレクションから削除されます。場合します。ASPXAUTH の cookie の削除は、次の要求が処理されるとき、ユーザーはログイン ページにリダイレクトされます。

これら 2 つのシナリオに関するトラブルシューティングを行うには、同じようにします。 ログイン ページにリダイレクトする前に同様の要求を確認します。このページへの要求では、cookie を生成する場合になります何かを調査します。

詳細については、次の文書番号をクリックして、マイクロソフト サポート技術情報の資料をご参照ください。

306070数および Internet Explorer の cookie のサイズの制限


Fiddler を使用すると、クライアントに送信される HTTP ヘッダーを表示します。トラフィックをキャプチャした後は、要求をダブルクリックし、Set-cookie ヘッダーを表示するヘッダーをクリックします。ログインに成功をトレースする場合は、ログインに成功の応答に Set-cookie ヘッダーが表示されます。

Fiddler をダウンロードするには、次の Fiddler の Web サイトを参照してください。
シナリオ 3

要求がクライアントから移る後、は、送信されるパケットに影響を与えるさまざまな層があります。ネットワーク デバイスが cookie を削除するかどうかを確認するのには、クライアントとサーバーでネットワーク トレースをキャプチャし、cookie の要求の本文にする必要があります。Cookie が送信されたことを確認するのにはクライアントの要求を確認し、サーバーが cookie を受信したことを確認するのにはサーバーのトレースを確認するには。

クライアントからの要求

これは、ユーザーが認証された後に GET 要求です。フォーム認証チケット情報が青でハイライトされます。これは、cookie の情報が、クライアントを離れたことを確認します。ネットワーク モニターなどのネットワーク キャプチャ ツールを使用すると、実際には、アダプターを通過するトラフィックを参照してください。
47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c   GET http://local68 6f 73 74 2f 46 6f 72-6d 73 41 75 74 68 4c 6f   host/FormsAuthLo
67 54 65 73 74 2f 57 65-62 46 6f 72 6d 31 2e 61 gTest/WebForm1.a
73 70 78 20 48 54 54 50-2f 31 2e 31 0d 0a 41 63 spx HTTP/1.1..Ac
63 65 70 74 3a 20 69 6d-61 67 65 2f 67 69 66 2c cept: image/gif,
…Other headers of the GET request…
63 68 65 0d 0a 43 6f 6f-6b 69 65 3a 20 2e 41 53 che..Cookie: .AS
50 58 41 55 54 48 3d 33-43 45 46 39 42 39 41 30 PXAUTH=3CEF9B9A0
43 33 37 41 44 46 36 33-45 36 42 44 33 37 42 36 C37ADF63E6BD37B6
39 43 44 41 32 35 30 30-30 46 38 30 37 32 38 46 9CDA25000F80728F
35 31 43 39 35 36 36 44-31 34 43 35 34 31 34 35 51C9566D14C54145
38 31 43 39 33 45 32 41-30 31 44 44 43 44 45 46 81C93E2A01DDCDEF
32 34 41 31 37 34 32 39-34 31 30 43 30 39 37 34 24A17429410C0974
42 33 45 43 42 30 36 34-32 32 38 45 33 35 33 39 B3ECB064228E3539
39 41 38 32 32 42 33 42-39 33 36 44 46 30 38 46 9A822B3B936DF08F
42 41 42 44 33 45 31 30-32 44 30 30 32 31 30 43 BABD3E102D00210C
32 45 31 33 39 38 30 37-39 42 32 33 35 32 39 46 2E1398079B23529F
34 46 35 44 37 34 41 3b-20 50 72 6f 66 69 6c 65 4F5D74A; Profile
3d 56 69 73 69 74 6f 72-49 64 3d 62 32 34 65 62 =VisitorId=b24eb

サーバー側の要求

サーバーに到達した要求を見ると、サーバーがクライアントから送信されたのと同じ情報を受信することになっていることを確認します。場合は、サーバーが同じ情報を受け取りませんでしたは、cookie が削除されたかを判断するのにはネットワーク上の他のデバイスを調査する必要があります。

注: Cookie を削除する ISAPI フィルターのインスタンスもありました。Web サーバーが cookie を受信したが、cookie が IIS ログに表示されないことを確認する場合は、ISAPI フィルターを確認します。問題が解決したかを表示するフィルターを削除する必要があります。

フォーム認証チケットをタイムアウトします。

フォーム認証チケットの有効期限が切れたかどうかは、リダイレクトするユーザーの他の一般的な原因です。フォーム認証チケットには、2 つの方法でタイム ・ アウトができます。最初のシナリオでは、絶対有効期限を使用する場合に発生します。絶対有効期限と有効期限が経過すると認証チケットの有効期限します。たとえば、20 分間の有効期限を設定して、ユーザーが 2時 00分 PM にサイトを訪問します。2時 20分 PM の後、ユーザーがサイトを訪問している場合、ログイン ページにユーザーがリダイレクトされます。

スライド式有効期限を使用する場合、シナリオはもう少し複雑です。場合は、有効期限の半分の有効期限が切れた後、ユーザーがサイトを訪問し、結果として得られるチケットが更新されます。たとえば、スライド式有効期限を使用して、20 分の有効期限を設定します。午後 2時 00分に、サイトにアクセスし、ユーザーは 2時 20分 PM に有効期限が設定されている cookie を受け取ります。有効期限は、ユーザーが 2時 10分 PM より後にサイトを訪問している場合にのみ更新されます。ユーザーは、2時 09分 PM にサイトを訪問、有効期限の半分が経過していないためにこのチケットは更新されません。待機して 12 分は、2時 21分 PM にサイトを参照、チケットが期限切れします。ユーザーは、ログイン ページにリダイレクトされます。

この種の問題は、フォーム認証 cookie とチケットの情報をログに記録する方法を 1 つの方法です。この方法では、IIS で、どのような値が、cookie を受信したかどうかを確認できます。HttpModuleを記述し、そのモジュールを要求パイプラインに接続して、これを行うことができます。必要な情報を取得するのには、アプリケーションのコードを変更する必要がありません。

付属のサンプルは、Microsoft.NET Framework 1.1 および.NET Framework 2.0 で動作し、全体のコメントには。サンプルには、次のファイルが含まれています:メモダウンロード リンクを提供、FormsAuthLogger.zip ファイルで指定されたコードです。

ここでの主な領域をポイントします。

常に、お気軽に目的のトピックに関するアイデアを送信するアドレス指定、将来の列、または、サポート技術情報を使用して、
それの質問のフォームです。
プロパティ

文書番号:910439 - 最終更新日: 2017/02/02 - リビジョン: 1

Microsoft ASP.NET 1.1, Microsoft ASP.NET 1.0, Microsoft ASP.NET 2.0

フィードバック