开发者

independent authenticated sessions with ASP.NET MVC 2 and Areas

开发者 https://www.devze.com 2023-04-01 05:13 出处:网络
i am developing a little CMS website (frontend area) where users can see news, explore products, etc and in the same site i have a backend area where CMS\'s content and ERP features are managed, this

i am developing a little CMS website (frontend area) where users can see news, explore products, etc and in the same site i have a backend area where CMS's content and ERP features are managed, this is just for company's staff so, my website is splitted in 2 areas, http://WEBSITEURL/Frontend/ and http://WEBSITEURL/Backend/

in the frontend Area my users are authenticated against a customer repository, but in my backend area, my users are authenticated against a company's staff开发者_JAVA百科 repository. i think i have to write my own MembershipProvider

i would use Authorize attribute in my controllers, but i want to know if it is possible to have and keep in session 2 authentications

i want to have ONE mvc project, not 2, one for frontend and the other for backend


No, you don't need to reinvent MembershipProvider. You also don't need to reinvent forms authentication. Indeed, you shouldn't. Doing security correctly is incredibly hard, even for experts. Will your new provider be vulnerable to a padding oracle attack, like the built-in providers were?

Let's take this one step at a time.

First, in order to have separate authentication tickets (cookies) for each area, you use the overload of SetAuthCookie which allows you to specify a cookie path. Set the path for each cookie such that the browser only sends the correct cookie for each area based on the URI path root (Frontend/ or Backend/, in your case).

AuthorizeAttribute will still work as-is. The browser, if you do the step above, will only send the correct cookie, which is signed and validated by forms authentication. AuthorizeAttribute just checks to see that the current provider has done this step, without concerning itself with the implementation.

Important I'm making a presumption which I haven't actually tested. I'm presuming forms auth checks the signed cookie against the request path to ensure that the path is the same. You'll want to test this yourself and implement it if forms isn't already doing this. Like I said, I presume that it is, but test to be sure.

Regarding "'authenticating' against a repository," don't confuse authentication and authorization. Authentication means "who are you?" Let forms auth do that. Authorization means "what are you allowed to do?" That is where you check your repositories.

So in the end, you'll do something like this, in the staff/backend area:

    [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();
                }
            }
0

精彩评论

暂无评论...
验证码 换一张
取 消