C#中权限管理.docx
《C#中权限管理.docx》由会员分享,可在线阅读,更多相关《C#中权限管理.docx(28页珍藏版)》请在冰豆网上搜索。
C#中权限管理
C#中使用位运算来实现权限管理
常用的位运算主要有与(&),或(|)和非(~),比如:
1&0=0,1|0=1,~1=0
在设计权限时,我们可以把权限操作转换为位运算来处理.
第一步,先建立一个枚举表示所有的权限操作:
[Flags]
publicenumPermissions
{
Insert=1,
Delete=2,
Update=4,
Query=8
}
[Flags]表示该枚举可以支持位运算,而枚举的每一项值,我们用2的n次方来赋值,这样表示成二进制时刚好是1=0001,2=0010,4=0100,8=1000等,每一位表示一种权限,1表示有该权限,0表示没有.
接下来是权限的运算:
1.权限的加法,使用与运算来实现.我们知道,0001|0100=0101,这样就表示同时具有第一位和第三位的权限了,枚举表示为:
Permissionsper=Permissions.Insert|Permissions.Update
2.权限的减法,使用与运算+非运算来实现,如上面要去掉Insert权限,操作为:
Permissionsper&=~Permissions.Insert
即是0101&~0001=0101&1110=0100
3.权限的判断,使用与运算,当判断用一用户是否具有该操作权限时,要把用户的的权限与操作权限进行与运算,如果得到的结果仍是操作权限,则表示用户具有该权限:
Permissionsper=Permissions.Insert|Permissions.Update;
if(per&Permissions.Insert=Permissions.Insert)
{
//有操作权限
}
比较过程为0101&0001=0001,0001的0位用与运算把其它位都置成0,变成只比较1的这一位.
权限角色管理模块
在开发很多项目的时候,都会用到用户权限管理,我也在很多项目里做过权限控制,所以,我也总结出一套条理清晰的角色权限控制体系.并且完善,减少模块的耦合度,做成一个独立的模块,用在很多项目里.
先来看看管理界面的效果图:
1.系统管理菜单
2.权限管理。
设置权限类别和权限信息。
3.角色管理
4.为角色分配权限。
5.为用户分配角色
有时间我会再想想多层权限控制的问题,来实现权限的递归控制.
经典的用户权限管理,数据结构分析设计
Postedon2010-07-0618:
35MARTIALIS阅读(130)评论(0)编辑收藏所属分类:
ASP.NET,sqlserver
实现业务系统中的用户权限管理--设计篇
B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。
因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些XX的“非法用户”将会将他们彻底的“拒之门外”。
下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。
需求陈述不同职责的人员,对于系统操作的权限应该是不同的。
优秀的业务系统,这是最基本的功能。
∙
∙可以对“组”进行权限分配。
对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。
所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。
∙权限管理系统应该是可扩展的。
它应该可以加入到任何带有权限管理功能的系统中。
就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。
∙满足业务系统中的功能权限。
传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。
关于设计
借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。
为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。
我们先来分析一下数据库结构:
首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。
如下图:
这三个表之间的关系是多对多的,一个权限可能同时属于多个管理组,一个管理组中也可能同时包含多个权限。
同样的道理,一个人员可能同时属于多个管理组,而一个管理组中也可能同时包含多个人员。
如下图:
由于这三张表之间存在着多对多的关系,那么它们之间的交互,最好使用另外两张表来完成。
而这两张表起着映射的作用,分别是“actiongroup”表(以下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”),前者映射了权限表与管理组表之间的交互。
后者映射了人员表与管理组表之间的交互。
如下图:
另外,还需要一张表来控制系统运行时左侧菜单中的权限分栏,也就是“权限分栏表”,如下图:
根据上面的分析,我们进行数据库结构设计,如下图:
点击这里查看权限管理系统数据表字段设计
为了能够进行良好的分析,我们将数据库结构图拆分开来,三张实体表的作用已经很清晰,现在我们来看一下两张映射表的作用。
一权限映射表如下图:
首先,我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。
看图中的红圈,先看gorupid字段相关联,这种关联方式在实际数据库中的表现如下图:
如图中所示,管理组表中“超级管理员”的groupid为1,那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。
使用groupid字段关联,是为了查到一个管理组能够执行的权限有哪些。
但这些权限的详细信息却是action字段关联所查询到的。
action字段相关联在数据库中的表现如下图:
通过这种关联,才查询到权限映射表之中那些权限的详细信息。
综合起来,我们就知道了一个管理组可以执行的权限有哪些,以及这些权限的详细信息是什么。
或许你会问,为什么不使用actionid字段相关联呢?
因为:
∙权限表中的id字段在经过多次的数据库操作之后可能会发生更改。
∙权限映射表中仅仅记录着一个管理组可以执行的权限。
∙一旦权限表中的id更改,那么权限映射表中的记录也就更改了。
∙一个管理组可以执行的权限势必将出错,这是非常不希望的。
考虑到上面的情况,所以应该使用action字段相关联,因为:
∙在权限表中,id可能发生变化,而action字段却是在任何情况下也不可能发生变化的。
∙权限映射表中记录的action字段也就不会变。
∙一个管理组可以执行的权限就不会出错了。
二人员映射表如下图:
我们来了解一下人员映射表与管理组表以及人员表之间的字段关联,如下图:
看图中的红圈部分,先看groupid字段关联,这种关联方式在数据库中的表现如下图:
如图,“超级管理员”组的groupid为1,我们再看人员映射表,admin属于超级管理员组,而administrator属于超级管理员组,同时也属于管理员组。
使用这种关联方式,是为了查到一个管理组中的人员有谁。
和上面一样,人员的详细信息是靠id字段(人员映射表中是masterid字段)关联查询到的。
id字段(人员映射表中是masterid字段)关联表现在数据库中的形式如下图:
一个人员可能同时属于多个“管理组”,如图中,administrator就同时属于两个“管理组”。
所以,在人员映射表中关于administrator的记录就会是两条。
这种关联方式才查询到管理组中人员的详细信息有哪些。
综合起来,才可以知道一个管理组中的人员有谁,以及这个人员的详细信息。
再结合上面谈到的权限表和权限映射表,就实现了需求中的“组”操作,如下图:
其实,管理组表中仅仅记录着组的基本信息,如名称,组id等等。
至于一个组中人员的详细信息,以及该组能够执行的权限的详细信息,都记录在人员表和权限表中。
两张映射表才真正记录着一个组有哪些人员,能够执行哪些权限。
通过两张映射表的衔接,三张实体表之间的交互才得以实现,从而完成了需求中提到的“组”操作。
我们再来看一下权限分栏表与权限表之间的交互。
这两张表之间的字段关联如下图:
两张表使用了actioncolumnid字段相关联,这种关联方式在数据库中的表现如下图:
如图所示,通过这种关联方式,我们可以非常清晰的看到权限表中的权限属于哪个分栏。
现在,数据库结构已经很清晰了,分配权限的功能以及“组”操作都已经实现。
下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。
为什么使用这种数据库设计方式搭建起来的系统可以重用呢?
∙三张实体表中记录着系统中的三个决定性元素。
“权限”,“组”和“人”。
而这三种元素可以任意添加,彼此之间不受影响。
无论是那种类型的业务系统,这三个决定性元素是不会变的,也就意味着结构上不会变,而变的仅仅是数据。
∙两张映射表中记录着三个元素之间的关系。
但这些关系完全是人为创建的,需要变化的时候,只是对数据库中的记录进行操作,无需改动结构。
∙权限分栏表中记录着系统使用时显示的分栏。
无论是要添加分栏,修改分栏还是减少分栏,也只不过是操作记录而已。
综上所述,这样设计数据库,系统是完全可以重用的,并且经受得住“变更”考验的。
总结:
此套系统的重点在于,三张实体表牢牢地抓住了系统的核心成分,而两张映射表完美地映射出三张实体表之间的交互。
其难点在于,理解映射表的工作,它记录着关系,并且实现了“组”操作的概念。
而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。
附录:
权限管理系统数据表的字段设计
下面我们来看看权限管理系统的数据库表设计,共分为六张表,如下图:
action表:
action表中记录着系统中所有的动作,以及动作相关描述。
actioncolumn表:
actioncolumn表中记录着动作的分栏,系统运行时,左侧菜单栏提供了几块不同的功能,每一块就是一个分栏,每添加一个分栏,该表中的记录就会增加一条,相对应的,左侧菜单栏中也会新增机一个栏。
actiongroup表:
actiongroup表记录着动作所在的组。
groupmanager表:
groupmanager表记录着管理组的相关信息,每添加一个管理组,这里的记录就会增加一条。
mastergroup表:
mastergroup表记录着管理员所在的管理组,由于一名管理员可能同同时属于多个组,所以该表中关于某一名管理员的记录可能有多条。
master表:
master表记录着所有管理员的信息,每添加一个管理员,该表就会增加一条记录。
ASP.NET最简单的用户权限管理
前些时间看到中国微软做的FrienDev开源项目,发现他们有个思路做用户权限管理的方法。
首先在网站上面建几个需要权限才可以访问的目录,再建一个就是不需要权限就可以访问的目录,例如:
需要权限的会员管理页面:
Member,公共页面:
Public
然后添加一个空项目StBusiness进来,添加一个类AuthenticationModule,再做一个ApplicationSettings.cs类,用来记录文件的路径与常量,在AuthenticationModule类里面继承IHttpModule接口
publicclassAuthenticationModule:
IHttpModule
{
}
在类里添加初始化方法
publicvoidInit(HttpApplicationcontext)
{
context.AcquireRequestState+=newEventHandler(context_AcquireRequestState);
}
添加测试过程
privatevoidcontext_AcquireRequestState(objectsender,EventArgse)
{
HttpContextcontext=HttpContext.Current;
stringpath=context.Request.Path.ToLower();
//只处理aspx文件,因为其他文件无法获得Session对象,无法判断是否已经登录
if(path.EndsWith(".aspx"))
{
//如果用户没有登录就會返回false
if(!
UserRules.Instance.IsCurrentUserLogined)
{
//对于公共文件夹和根目录的文件不做判断
if(path.StartsWith("/"+ApplicationSettings.PUBLICFOLDERNAME+"/")==false&&!
(path.LastIndexOf("/")==0))
{
//跳转到公共页面首页
context.Response.Redirect(ApplicationSettings.PUBLICLOGOUTFILENAME,false);
context.ApplicationInstance.CompleteRequest();
}
}
else //登陆了再查看是587还是普通用户
{
if(path.ToLower()==ApplicationSettings.MemberAe.ToLower()||path==ApplicationSettings.MemberSe.ToLower())
{
if(context.Session[ApplicationSettings.SESSIONUSERIDKEY].ToString()!
="587")
{
//跳转到原来页面
context.Response.Redirect(ApplicationSettings.MemberStm,false);
context.ApplicationInstance.CompleteRequest();
}
}
}
}
}
在代码上面用到了一个检查是否登陆的方法UserRules.Instance.IsCurrentUserLogined
添加UserRules类,用户登陆用单例模式来实现代码如下:
publicclassUserRules
{
privatestaticUserRules_instance;
publicstaticUserRulesInstance
{
get
{
if(_instance==null)
{
_instance=newUserRules();
}
return_instance;
}
}
privateUserRules()
{
}
}
然后再在UserRules类里面添加IsCurrentUserLogined方法
publicboolIsCurrentUserLogined
{
get
{
if(HttpContext.Current.Session["UID"]==null)
{
returnfalse;
}
returntrue;
}
}
最后一步,就是在web.congif里面配置
这样就完成的一个最简单的用户权限管理功能,发觉对小型简单的网站来说,这样不愧是好办法。
C#ASP.NET最常用的通用权限的3个方法例子展示。
在UserPermission.aspx的例子如下,原文件的位置如下图:
参考代码如下:
代码
//------------------------------------------------------------
// All Rights Reserved , Copyright (C) 2010 , Jirisoft , Ltd.
//------------------------------------------------------------
using System;
using System.IO;
using System.Data;
namespace DotNet.Web.Permission
{
using DotNet.Service;
using DotNet.Utilities;
using Jirisoft.Permission.Model;
using Jirisoft.Permission.Business;
///
/// UserPermission
/// 用户当前权限的获取例子
///
/// 修改纪录
///
/// 版本:
1.0 2010.07.08 JiRiGaLa 写好例子程序方便别人学习。
///
/// 版本:
1.0
///
/// JiRiGaLa
/// 2010.07.08
///
///
public partial class UserPermission :
BasePage
{
protected void Page_Load(object sender, EventArgs e)
{
// 当然是用户需要登录,否则哪里能知道,现在是判断谁的权限啊?
this.UserInfo = Utilities.Login("Jirigala_Bao@H", String.Empty);
// 1 判断用户是否有某个操作权限(在服务器上判断)
// 访问职员的身份证列字段的操作权限
string permissionItemCode = "Staff.Column.IDCard.Access";
ServiceManager.Instance.PermissionService.IsAuthorizedByUser(this.UserInfo, this.UserInfo.Id, permissionItemCode);
// 2 获取用户模块菜单列表
this.GetUserModules();
// 3 获取用户权限列表
this.GetUserPermission();
}
///
/// 2 获取用户模块菜单列表
///
private void GetUserModules()
{
// 就一行代码,就可以获取当前用户的所有可以访问的模块,然后自己想怎么处理就处理,例如变成树形菜单等等
DataTable dtUserModule = ServiceManager.Instance.PermissionService.GetModuleDTByUse