4

IIS統合パイプラインのシーケンスと動作についてこれまでに見た中でおそらく最も役立つMSDNの記事を見つけました。しかし、それは認証に関して興味深い質問を提起します。

フォーム認証は、パイプラインの非常に早い段階で「実行中」として表示されます。ASP.NET MVCルーティングやコントローラー実行などの「実行」ハンドラーについては、後で説明します。しかし、ASP.NETMVCの認証ストーリーは次のようになることがよくあります。

public ViewResult Login(LoginModel login)
{
    if (ModelState.IsValid)
    {
        if (Membership.ValidateUser(...)){
            FormsAuthentication.SetAuthCookie(...);
        }
    }
    //...
}

上記のコードは、（フォーム）認証が、はるかに初期の「認証」IISステージではなく、「実行」ハンドラーステージ中に発生することを示しています。

誰かがこの一見矛盾を明らかにすることができますか？

これについての私自身の推測では、IISの「認証」ステージは、メンバーシッププロバイダーが構成されていない場合、指示されたときにFormsAuthenticate.Authorize（...）を実行します。ただし、独自のメンバーシッププロバイダーを構成すると、IISの「認証」ステージは事実上何も実行せず、「実行」ステージを待機して、独自の認証コードを実行できるようにします。

私の推測が正しければ、自分のメンバーシッププロバイダーを構成した場合、「状態の取得」IISステージも期待どおりに機能しないことを意味します。セッションが確立されないため、確立されたセッションはまだ「表示」されません。 MVCコントローラー内で認証手順を実行するまで。または、「Authenticate」および「Acquire State」関連のアプリケーションイベントが「保留」され、コントローラーが認証コードを実行するまで発生しない可能性がありますか？

はい？いいえ？

4

1 に答える 1

1

ここで起こっていることは2つあり、それは理解できる混乱を招きます。

  1. あなたが学んだように、FormsAuthenticationモジュールは非常に早い段階で実行されます。ただし、そのモジュールは主に、フォームのauth cookieを確認し、その信頼性を確立することを目的としています。それが信頼できる場合は、ASP.NETが使用する正しいIDプリンシパルを設定します。
  2. MVCプロジェクトで通常表示される認証コードは、ユーザーのログインに関するものであり、資格情報が正しい場合は、フォーム認証のCookieを後で処理するように設定します。
于 2012-12-15T17:13:26.467 に答える