0

私は、ユーザーがニュースを見たり、製品を探索したりできる小さな CMS Web サイト (フロントエンド エリア) を開発しています。同じサイトに、CMS のコンテンツと ERP 機能が管理されるバックエンド エリアがあります。これは会社のスタッフ専用なので、私の Web サイトhttp://WEBSITEURL/Frontend/とhttp://WEBSITEURL/Backend/の 2 つの領域に分かれています。

フロントエンド エリアでは、ユーザーは顧客リポジトリに対して認証されますが、バックエンド エリアでは、ユーザーは会社のスタッフ リポジトリに対して認証されます。独自の MembershipProvider を作成する必要があると思います

コントローラーで Authorize 属性を使用しますが、セッション 2 の認証を維持できるかどうかを知りたいです。

2 つではなく 1 つの mvc プロジェクトが必要です。1 つはフロントエンド用、もう 1 つはバックエンド用です。

4

1 に答える 1

1

いいえ、再発明する必要はありませんMembershipProvider。また、フォーム認証を作り直す必要もありません。確かに、あなたはすべきではありません。専門家であっても、セキュリティを正しく行うことは非常に困難です。新しいプロバイダーは、組み込みプロバイダーのように、パディングオラクル攻撃に対して脆弱ですか？

これを一歩ずつ進めていきましょう。

まず、エリアごとに個別の認証チケット（Cookie）を設定するために、オーバーロードを使用しSetAuthCookieてCookieパスを指定できます。ブラウザがURIパスルート（Frontend/またはBackend/、この場合は、）に基づいて各領域に正しいCookieのみを送信するように、各Cookieのパスを設定します。

AuthorizeAttributeそのまま動作します。上記の手順を実行すると、ブラウザは正しいCookieのみを送信します。このCookieは、フォーム認証によって署名および検証されます。AuthorizeAttribute実装に関係なく、現在のプロバイダーがこのステップを実行したことを確認するだけです。

重要私は実際にテストしていない推定を行っています。フォーム認証は、署名されたCookieをリクエストパスと照合して、パスが同じであることを確認していると思います。フォームがまだこれを行っていない場合は、これを自分でテストして実装することをお勧めします。私が言ったように、私はそうだと思いますが、確かめるためにテストしてください。

「リポジトリに対する「認証」」に関しては、認証と承認を混同しないでください。認証とは「あなたは誰ですか？」という意味です。フォーム認証にそれをさせましょう。承認とは、「何ができるか」という意味です。ここでリポジトリをチェックします。

したがって、最終的には、スタッフ/バックエンド領域で次のようなことを行います。

    [HttpPost]
    public ActionResult LogOn(LogOnModel model, string returnUrl)
    {
        if (ModelState.IsValid)
        {
            if (Membership.ValidateUser(model.UserName, model.Password))
            {
                if (StaffRepository.AuthorizedUser(model.UserName))
                {
                    FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe, pathForBackend);
                    return RedirectTo....
                }
                else
                {
                    return MyUnauthorizedAction();
                }
            }
于 2011-09-01T13:05:34.330 に答える