基于操作+角色的授权方案

微软的forms授权是基于角色和用户的，这样可以很容易的限定那些用户，角色可以访问某个页面目录的权限。但是正如需求工程讨论的，有时候客户很不容易满足，现在我的客户要求系统允许他们自己可以定义角色可以做那些操作，也就是说角色可以做什么是可定义的用户随时可以修改的，这样如果使用微软的forms认证就实现不了了，我们不可能在用户每次自定义了角色的操作权限之后，都去修改一次web.config中的定义，怎么办？

客户有提出需求的权利，我们有满足客户需求的智慧，前提是客户愿意为自己的需求付出银子，呵呵。角色可以做的操作是可定义的，所以我们需要在数据库中存储角色，和角色可以做的操作，以及用户属于那个资源上的那个角色。前一句话中引出了一个新的概念“资源”，它可以是CMS内容管理系统中的频道，也可以是论坛中的版面，就是用户是“A频道”的“管理员”，但是不是“B频道”的管理员中的“A频道”，“B频道”。我们可以据以上描述设计概念模型如下：
 

（由于我现在正在做一个论坛的项目，所以上面的表都有Forum的前缀，_tab是我们规范中的后缀）
以上模型中定义了角色，操作，角色操作定义关系，以及版面用户角色对应关系，通过上面的模型我们就可以实现用户要求的自定义角色可以做那些操作的需求了。

有了数据库的概念模型，还是不够的，我们还需要设计一下，让我们这套授权方案的使用和微软的forms认证一样方便。Forms认证可以通过web.config的定义角色页面的访问权限，我们这套授权方案，肯定是不能这样做的，因为我们的角色可以做什么是可定义的。但是我们的权限方案中也有不变的元素，那就是Action---操作，而每一个页面中有那些操作，这一点也是一定的，所以我们可以给页面指定其操作，在用户访问时再根据用户属于的角色来得到角色可以执行的操作来判断当前用户是否可以进入页面，如果可以进入再在实际操作中判断用户是否有在某个资源上执行的权限。

以上内容说了操作+角色授权方案的实现思路，由于时间关系，下一随笔再和大家讨论这套方案如何具体实现。

 

 

 

接上文，上一篇随笔说了基于操作+角色授权方案的设计思路，本随笔谈谈如何实现，可以方便高效的使用此方案。

在这套授权方案中角色是用户可配置的，而操作是死的，我们在程序中实现了什么功能就有什么样的操作，所以我们充分利用这一点，为了使用方便我们将操作作为PageBase（项目中统一的Page基类）的Attribute来定义，然后在PageBase对应页面执行PreLoad事件时读取此页面上定义的Attribute属性中的操作，然后读取当前用户可执行的操作，对比得到用户是否有访问该页面的权限。
ActionsAttribute的实现很简单，就是定义了一个只读的string数组来存放页面功能中的操作。其实现如下

[global::System.AttributeUsage(AttributeTargets.Class, Inherited = true, AllowMultiple = true)] public sealed class ActionsAttribute : Attribute { public readonly string[] PageActions; public ActionsAttribute(params string[] actions) { PageActions = actions; } } 我们需要在PageBase类中实现对ActionsAttribute（即当前页实现操作）的读取和对权限的判断，关键代码如下 PageBase中的实现 protected override void OnInit(EventArgs e) { PreLoad += new EventHandler(IfNoPermission); base.OnInit(e); } protected static Type _permissionAttributeType = typeof(ActionsAttribute); protected string[] _actions = null; private static Dictionary<Type, string[]> _pageActionsDict = new Dictionary<Type, string[]>(); protected string[] _allowedRoles = null; protected virtual bool CanEnterPage() { if (_actions == null) { Type t = this.GetType(); if (_pageActionsDict.ContainsKey(t)) { _actions = _pageActionsDict[t]; } else { object[] attributes = t.GetCustomAttributes(_permissionAttributeType, true); if (attributes != null && attributes.Length > 0) { List<string> actionList = new List<string>(); foreach (object attr in attributes) { ActionsAttribute actionsAttr = attr as ActionsAttribute; if (actionsAttr != null && actionsAttr.PageActions != null && actionsAttr.PageActions.Length > 0) { actionList.AddRange(actionsAttr.PageActions); } } _actions = actionList.ToArray(); } else { _actions = new string[] { }; } #if !DEBUG if (_pageActionsDict.ContainsKey(t) == false) { _pageActionsDict.Add(t, _actions); } #endif } } if (_actions != null && _actions.Length > 0) { return LoginUser.CanDoAction(_actions); } return true; } protected virtual void RedirectIfHasNoPermission() { Response.Redirect("~/error/permission.htm", true); } protected virtual void IfNoPermission(object sender, EventArgs e) { if (!CanEnterPage()) { RedirectIfHasNoPermission(); } }

 

大家都知道读取Attribute是通过反射来做的，其性能会有问题，所以我们生命了一个静态的成员变量_pageActionsDict来保存解析出来的Attribute和Page类型的对应字典，这样所有页面的Attribute都仅需要读取一遍，对性能几乎没有影响。
在上面的方法中我们使用了LoginUser.CanDoAction方法，其中LoginUser是PageBase的一个属性，表示当前登录的用户，在User类中有对当前用户权限的判断。其相关代码如下：

 

///   <summary>
///  判断用户是否具有某几个角色中的一种
///   </summary>
///   <param name="roleNames"> 几种角色 </param>
///   <returns> true拥有一种，否则没有 </returns>
public   bool  CanDoAction( params   string [] actions)
{
     return   true ;
}

///   <summary>
///  判断当前用户是有对某资源执行某种操作的权限
///   </summary>
///   <param name="boardId"> 版面id </param>
///   <param name="action"> 操作 </param>
///   <returns> true：有权限，false：无权限 </returns>
public   bool  CanDoAction( int  boardId,  string  action)
{
     return   true ;
}

 

这两个方法没有具体实现，不过有了设计思路实现是很简单的。

我们在具体使用中，就是直接给具体的Page类加上Attribute了，如下示例代码：

    [Actions(ActionsConst.EnterAdmin)]
     public   partial   class  Default : PageBase
    {
         protected   void  Page_Load( object  sender, EventArgs e)
        {
            
        }
    }

 

其中ActionsConst是系统中所有操作的常量定义类。

全文完。

转载自：http://www.cnblogs.com/yukaizhao/archive/2008/11/21/permission_action_role_shixian.html