[讨论]二、ASP.NET MVC控制到Action参数的权限对策

继上一篇 [讨论]ASP.NET MVC控制到Action参数的权限对策 后，我总觉得我的做法是不正确的，但走不出误区，昨晚和程序网友们讨论后，找出了一些让我放弃这种做法的理由。

 

 1.过分依赖某一个MVC架构的权限设计，不够通用。

 2.权限控制过于复杂。

 3.最关键是有种莫名其妙的别扭感。

 

好了，让我继续尝试下去，失败下去吧。以下的内容有一部分操作是基于上一篇提及到的，我就不在这里描述了。

 

Model First，这次类图比上一次简洁了很多，只有一个Role角色类。

 

接着我们看看AccountController，这是账号管理的地方。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using Domain;
using Repository;
using Moq;
using WebUI.Views.Account;

namespace WebUI.Controllers
{
    public class AccountController : Controller
    {
        private IUserRepository<SysUser> _Repository;

        //
        // GET: /Account/
        [HttpGet]
        public ActionResult Login()
        {
            return View();
        }

        [HttpPost]
        public ActionResult Login(Account_LoginVM FormUser)
        {
            //初始化模拟数据
            this.initMockData();

            SysUser DbUser = this._Repository.findByUserID(FormUser.UserID);

            if (DbUser == null)
            {
                HttpContext.Response.Write("不存在此用户！");
                HttpContext.Response.End();
            }
            else if (FormUser.UserPwd != DbUser.UserPwd)
            {
                HttpContext.Response.Write("密码错误！");
                HttpContext.Response.End();
            }

            HttpContext.Session["User"] = DbUser;

            return RedirectToRoute(new { controller = "Home", action = "Index" });
        }

        private void initMockData()
        {
            var mock =new Mock<IUserRepository<SysUser>>();

            //角色链
            var roleList= new List<UserRole>()
                         {
                             new UserRole()
                            {
                              Id=1,
                              RoleName="Register",
                            },
                            //暂时去掉Admin权限。
                            // new UserRole()
                            //{
                            //  Id=2,
                            //  RoleName="Admin",
                            //}
                         };

            mock.Setup(m => m.findByUserID("HuntSoul"))
                .Returns
                (
                  new SysUser()
                  {
                      Id = 1,
                      UserID = "HuntSoul",
                      UserPwd = "654321",
                      NickName = "BackDoor", //UI Modual，用于ACTION参数验证用的。
                      Roles = roleList
                  }
                );

            _Repository = mock.Object;
        }
    }
}

和上一篇AccountController没有多少变化，因为去除了几个资源管理类，所以变得更简洁。注意第61行注释的内容，是一个Admin角色，暂时我们先不提供给这个权限。现在我们登陆一下。输入ID:HuntSoul  Pwd:654321  XD不解释~

 

 

结果当然是登录不了啦，因为过滤器对角色和用户账号限制了范围。

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using WebUI.ActionFilter;

namespace WebUI.Controllers
{
    [HandleError]
    public class HomeController : Controller
    {
        //用户通用过滤器，可以配置角色和用户ID的权限组合来过滤。
        [UserAuthorize
            (
            Roles =new string[]{ "Admin"},
            UserID=new string[]{"Admin"}
            )
        ]
        public ActionResult Index()
        {
            ViewData["Message"] = "Index Action 验证成功！";

            return View();
        }

        //Action级别下参数过滤
        [FilterByUserInfo
            (
             Roles=new string[]{"Admin"}
            )
        ]
        public ActionResult Manage(string Modual)
        {
            ViewData["Message"] = "模块进入验证成功！";

            return View();
        }
    }
}

 

 

 相比上一次的过滤器，这次改进了少少。

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using Domain;

namespace WebUI.ActionFilter
{
    public class UserAuthorizeAttribute:ActionFilterAttribute
    {
        /// <summary>
        /// 角色链
        /// </summary>
        public string[] Roles { get; set; }

        /// <summary>
        /// 用户ID链
        /// </summary>
        public string[] UserID { get; set; }

        protected SysUser _User { get; set; }

        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            _User = HttpContext.Current.Session["User"] as SysUser;

            var rolesResult = from a in _User.Roles
                         from b in Roles
                         where a.RoleName.Equals(b)
                         select a;

            var userIDResult = from a in _User.UserID
                               from b in UserID
                              where a.Equals(b)
                              select a;

            if (rolesResult.ToList().Count == 0 && userIDResult.ToList().Count == 0)
            {
                HttpContext.Current.Response.Write("没有权限！");
                HttpContext.Current.Response.End();
            }
        }

        public override void OnResultExecuted(ResultExecutedContext filterContext)
        {
            base.OnResultExecuted(filterContext);
        }
    }
}

 

这次的过滤器，主要功能是，能够对角色或者用户账号进行过滤，基于组合形式:) 好了不废话，我们先去掉Admin角色的注释再一次登录看看。

 

终于登录成功了，好了，废话了那么多终于进入我们一直以来的问题了。可以看到，图片上有几个模块入口，它们指向是同一个Action，但传递的是不同的Action参数，而如果需求是要做权限管理，该如何？这是比较常见的情况，正如上一篇所用的方法，显得太繁琐了，这次的思路是针对特定的Action再写一个特定的过滤器去处理权限分配问题，我们先看看这个过滤器。

 

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace WebUI.ActionFilter
{
    public class FilterByUserInfoAttribute:UserAuthorizeAttribute
    {
        public override void OnActionExecuting(System.Web.Mvc.ActionExecutingContext filterContext)
        {
            base.OnActionExecuting(filterContext);

            //配置你想额外做参数权限控制的地方，有点别扭。
            var moduel = filterContext.RouteData.Values["id"].ToString();

            if (_User.NickName != moduel)
            {
                HttpContext.Current.Response.Write("没有权限！");
                HttpContext.Current.Response.End();
            }
        }

        public override void OnActionExecuted(System.Web.Mvc.ActionExecutedContext filterContext)
        {
            base.OnActionExecuted(filterContext);
        }
    }
}

其实这个只不过是针对特定问题的过滤器，可以说，这是唯一一个让我觉得这次方案别扭的地方 XD 。意图大意是如果参数不等于用户某一个属性，如这里的NickName，同样不具有权限查看。同理可以得出对用户其他属性的权限处理。

 

我们看看AccountController的第77行代码，可以发现，我们这里的NickName设置了为BackDoor。。。可能这里的属性用得不恰当，凑合看吧，不影响分析思路。这里BackDoor意味着，如果Action Manage(string modual) 参数不为BackDoor我们就没有权限，我们先看看Index页面的ActionLink.

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    Home Page
</asp:Content>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2><%= Html.Encode(ViewData["Message"]) %></h2>
    
    <ul>
       <li><%= Html.ActionLink("游客入口", "Manage", new { id = "Guest" })%></li>
       <li><%= Html.ActionLink("前台管理", "Manage", new { id = "UI" })%></li>
       <li><%= Html.ActionLink("后台管理", "Manage", new { id = "BackDoor" })%></li>
       <li><%= Html.ActionLink("权限管理", "Manage", new { id = "Authority" })%></li>
    </ul>
    
    <p>
        To learn more about ASP.NET MVC visit <a href="http://asp.net/mvc" title="ASP.NET MVC Website">http://asp.net/mvc</a>.
    </p>
</asp:Content>

可以看出，游客入门这条LINK传递的是Guest,而前台管理传递的是UI。。。等等。正常来说我们只能打开传递信息为BackDoor的模块，为了直观点说明问题，我还是把所有情况截了图。

 

点击“游客入口”

点击“前台管理”

点击“后台管理”

好了后面那个不用展示了吧。现在我们把我们的NickName改为UI看看结果。

 

 mock.Setup(m => m.findByUserID("HuntSoul"))
                .Returns
                (
                  new SysUser()
                  {
                      Id = 1,
                      UserID = "HuntSoul",
                      UserPwd = "654321",
                      NickName = "UI", //UI Modual，用于ACTION参数验证用的。
                      Roles = roleList
                  }
                );

 

点击“前台模块”模块

点击“后台模块”模块

 

好了，演示流程结束，应该可以说明问题了，还是那句，我只想找一种更好的方法解决这个问题。希望各位尽力拍砖~XD

 

完整Demo