基于MVC Action粒度的权限管理（续）_sql

概述Asp.Net大型项目实践(11)-基于MVC Action粒度的权限管理【续】【源码在这里】（在线demo，全部源码）接上篇Asp.Net大型项目实践(10)-基于MVC Action粒度的权限管理（在线demo，全部源码）在线Demo : 地址：http://218.60.8.35:1234/ 服务器：网通端口：不要禁用1234端口应该就可以访问注意：连了数据库的，时间仓促肯定有漏洞， Asp.Net大型项目实践(11)-基于MVC Action粒度的权限管理【续】【源码在这里】（在线demo，全部源码）

接上篇Asp.Net大型项目实践(10)-基于MVC Action粒度的权限管理（在线demo，全部源码）

在线Demo :

地址：http://218.60.8.35:1234/

服务器：网通

端口：不要禁用1234端口应该就可以访问

注意：连了数据库的，时间仓促肯定有漏洞，不要捣乱哈：）

登录用户： 1.用户名：牛头人战士密码:000000 权限：有全部菜单页面，不能进行数据库的更改 *** 作（不影响录入体验）

　　　　　 2.用户名：老虎MM 密码:000000 权限：少两个菜单页面，不能进行数据库的更改 *** 作（不影响录入体验）

　　　　　 3.用户名：admin 密码不公开权限：所有权限

　　　　　注：以上的实现都是通过权限管理s配置出的哈，没有任何硬编码

权限判断的边界

由于项目是基于MVC的，除去数据权限不说，功能权限的判断边界做在MVC 的Action上无疑是最好的选择，因为无论是一个页面，还是一个按钮，还是一次查询，都是通过Action请求实现的。这样我们只需要在每个 Action请求执行之前进行权限判断就可以了，也不用折腾RBAC里的资源+ *** 作=权限这么麻烦。

菜单权限和功能权限

其实在MIS项目中，大多数的权限判断粒度还是页面级的，再加上我们还需要根据权限动态生成用户的菜单，所以我们把权限分成“菜单权限”和“功能权限”

菜单权限：在用户登录验证后，每个页面的请求都必须通过权限验证。

功能权限：默认客户进入页面后，页面的相关 *** 作默认都不判断，只对显示维护出的功能权限进行权限判断。

这样有几个好处：一般情况下权限的配置简单了，因为只需要配置粗粒度的页面权限即可使用；增加了效率，不必每个Action执行之前都判断权限（虽然都做了缓存，但能少判断一次还是好的）；完全不影响细粒度的权限判断，随时都可以增加对任何一个Action的权限判定

如何取Action功能权限

我们通过反射把所有的Action权限全部取出来，这样在维护选取的时候就比较方便了，也不会产生录入错误，如下图：

大家用Demo可以体验到我们模糊输入Action名称就可以找到我们想要的Action的，因为是配置选取用也不用担心什么反射的效率问题，其实大家从demo可以看到速度还是挺快的，在我真实的项目中Action中有上万个，拉出来一样是瞬时的，所以我觉得有时候吧，也别过于“谈反射色变”，呵呵

通过反射获取所有Action的代码如下：

public IList<ActionPermission> GetAllActionByAssembly() { var result = new List<ActionPermission>(); var types = Assembly.Load("Demo.HIS.MVC").GetTypes(); foreach (var type in types) { if (type.BaseType.name == "BaseController")//如果是Controller { var members = type.getmethods(); foreach (var member in members) { if (member.ReturnType.name == "ActionResult")//如果是Action { var ap = new ActionPermission(); ap.Actionname = member.name; ap.Controllername = member.DeclaringType.name.Substring(0,member.DeclaringType.name.Length - 10); // 去掉“Controller”后缀 object[] attrs = member.GetCustomAttributes(typeof(System.ComponentModel.DescriptionAttribute),true); if (attrs.Length > 0) ap.Description = (attrs[0] as System.ComponentModel.DescriptionAttribute).Description; result.Add(ap); } } } } return result; }

返回的IList< ActionPermission >就是系统中所有Action的集合，大家可看到我们通过BaseController找到了项目中所有的Controller，再通过ActionResult找到Controller中所有的Action。

不知道大家注意下拉出的Action有个描述属性，这个属性是通过在Action上定义DescriptionAttribute实现的，这样通过反射就能取到中文描述了，例如：为了实现页面的选取方便，我们还要实现对IList< ActionPermission >的分页和模糊查询，因为是变量级集合，这里我们使用linq查询就可以了，代码如下：

Description("访问功能权限管理页面")] [VIEwPage] public ActionResult ActionPermission() { return VIEw(); }

public IList<ActionPermission> queryActionPList(string query,int start,int limit,out long total) { IList<ActionPermission> allActions = GetAllActionByAssembly(); total = (from a in allActions where a.Actionname.Tolower().Contains(query.Tolower()) select a).Count(); var result = (from a in allActions where a.Actionname.Tolower().Contains(query.Tolower()) select a).Skip(start).Take(limit); return new List<ActionPermission>(result); }

把权限判断相关的数据都缓存起来提高效率

我们把当前登录用户的：用户信息，拥有菜单权限，拥有功能权限放在Session里

我们把需要托管的所有Action功能权限放在 Appliction全局应用程序变量里

这样我们所有的权限相关判断都是从缓存中取数据，不需要频繁访问数据了。

相关代码懒得贴了，自己去下载的源码里翻吧....注意一下缓存相关都是通过ICache这个接口出的，搜一下就能找到

如何对每个Action进行拦截，在它执行之前判断权限

最土的办法就是在每个Action加一段权限判断的代码，哈哈...如果我要这样做的话，估计要被大家的砖头拍死。

看过本系列Asp.Net大型项目实践(7)-用Unity实现AOP之事务处理+为啥要用AOP（附源码）的朋友应该就能想到，这是一个典型的AOP应用场景。

由于Asp.net MVC的Filter机制其实就是Aop,所以我们直接使用它。熟悉Asp.net MVC的朋友估计知道里面其实自带的有一个AuthorizeAttribute的ActionFilter，但基本就是个玩具，本来我想继承它重写的，但无奈里面的filterContext没有ActionDescriptor属性，所以干脆不要它自己写个ActionFilter，代码如下：

using System;using System.Collections.Generic;using System.linq;using System.Text;using System.Web.Mvc;using System.Web;using System.Security.Principal;using Demo.HIS.Infrastructure.Facade.Authority;namespace Demo.HIS.MVC.CommonSupport.Filter{ /// <summary> /// 权限拦截 /// </summary> [AttributeUsage(AttributeTargets.Class | AttributeTargets.Method,AllowMultiple = false)] public class Authorizefilterattribute : ActionFilterattribute { public overrIDe voID OnActionExecuting(ActionExecutingContext filterContext) { if (filterContext == null) { throw new ArgumentNullException("filterContext"); } var path = filterContext.httpContext.Request.Path.Tolower(); if (path == "/" || path == "/Main/Login".Tolower() || path == "/Main/UserLogin".Tolower()) return;//忽略对Login登录页的权限判定 object[] attrs = filterContext.ActionDescriptor.GetCustomAttributes(typeof(VIEwPageAttribute),true); var isVIEwPage = attrs.Length == 1;//当前Action请求是否为具体的功能页 if (this.AuthorizeCore(filterContext,isVIEwPage) == false)//根据验证判断进行处理 { //注：如果未登录直接在URL输入功能权限地址提示不是很友好；如果登录后输入未维护的功能权限地址，那么也可以访问，这个可能会有安全问题 if (isVIEwPage == true) { filterContext.Result = new httpUnauthorizedResult();//直接URL输入的页面地址跳转到登陆页 } else { filterContext.Result = new ContentResult { Content = @"JsHelper.ShowError('抱歉,你不具有当前 *** 作的权限！')" };//功能权限d出提示框 } } } //权限判断业务逻辑 protected virtual bool AuthorizeCore(ActionExecutingContext filterContext,bool isVIEwPage) { if (filterContext.httpContext == null) { throw new ArgumentNullException("httpContext"); } if (!filterContext.httpContext.User.IDentity.IsAuthenticated) { return false;//判定用户是否登录 } var user = new CurrentUser();//获取当前用户信息 var controllername = filterContext.RouteData.Values["controller"].ToString(); var actionname = filterContext.RouteData.Values["action"].ToString(); if (isVIEwPage && (controllername.Tolower() != "main" && actionname.Tolower() != "masterpage"))//如果当前Action请求为具体的功能页并且不是MasterPage页 { if (user.MenuPermission.Count(m => m.Controllername == controllername && m.Actionname == actionname) == 0) return false; } else { var actions = ContainerFactory.GetContainer().Resolve<IAuthorityFacade>().GetAllActionPermission();//所有被维护的Action权限 if (actions.Count(a => a.Controllername == controllername && a.Actionname == actionname) != 0)//如果当前Action属于被维护的Action权限 { if (user.ActionPermission.Count(a => a.Controllername == controllername && a.Actionname == actionname) == 0) return false; } } return true; } }}

a.我的Authorizefilterattribute继承了ActionFilterattribute

b.重写ActionFilterattribute的OnActionExecuting(ActionExecutingContext filterContext)方法，这个方法表示在每个Action执行之前处理

c.返回页面的Action上面要加VIEwPageAttribute，这样我在Filter里才能区分当前Action是否为页面（注：由于是在Action执行之前，无法通过获取ActionResult的类型来判断）

d.权限判断和处理的逻辑自己看贴的代码里的注释，已经写的很清楚了

在哪儿加这个Authorizefilterattribute呢？一个一个给Action或Controller加都太麻烦了，还记得我们所有的 Controller都继承了BaseController吗？在他上面就完事了呗！这样整个系统要不权限就靠BaseController上的一个 Authorizefilterattribute说了算～，BaseController如下：

namespace Demo.HIS.MVC.CommonSupport{ // 所有Controller都要继承的基类 [Authorizefilter] [ExceFilter] public class BaseController : Controller { }}

使用FormsAuthentication实现登录验证

用户登录验证用的是.Net自带的Forms验证，它默认通过加密的cookies来实现用户的登录判断

登录代码如下：

[ExtResult] [Description("用户登录")] public ActionResult UserLogin() { string loginname = Request["loginname"]; string pwd = HospUser.GetPwdMD5(Request["pwd"]); if (!AuthorityFacade.ValIDate(loginname,pwd)) throw new ValIDationException("用户名密码错误，或用户状态不可用"); FormsAuthentication.SetAuthcookie(loginname,true);//加入from验证票据 Cache.RemoveSessionCache("currentuser");//清空当前用户信息缓存 return this.JsonFormat(new ExtResult { success = true }); }

//注销登陆 public ActionResult logout() { FormsAuthentication.SignOut(); Cache.RemoveSessionCache("currentuser");//清空当前用户信息缓存 return this.JsonFormat(new ExtResult { success = true }); }

大伙期待的源码：

虽然是从公司实际项目中扒出来的，但整个设计，思想，架构和关键代码基本都是我一个人搞的，而且业务相关的东西我都去掉了所以大家可以随便用。

里面可能涉及到不少东西还没有讲到，在以后的系列中会详细说明。

另外有人说源码编译报错缺少“HibernatingRhinos.NHibernate.Profiler.Appender.DLL”，你可以把这个DLL删除，再根据错误信息删除一行代码即可，这个其实是之前讲过的NHProfiler，NH生成sql查看工具用的DLL。

源码：HISDemo-10.rar

数据库（估计用sqlSERVER的比较多，所以我把数据库从oracle改成了sqlServer2005,直接附加就可以了）：HISDemoDb.rar

总结

　　权限管理这部分暂时就介绍到这里，以后有机会再给大家介绍数据权限，权限与工作流引擎集成，单点登录，多级授权等复杂的权限管理实现。大家可以看到上面介绍权限管理还是有些特点的：

1.充分利用MVC特点；

2.思路清晰；

3.验证逻辑简单；

4.维护方便；