权限设计方案

1、权限管理设计 博客分类： 设计设计模式数据结构应用程序权限设计我们在开发系统的时候，经常会遇到系统需要权限控制，而权限的控制程度不同有不同的设1. 基于角色的权限设计这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，所以微软就设 计出这种方案的通用做法，这种方案对于每一个操作不做控制，只是在程序中根据角色 对是否具有操作的权限进行控制；这里我们就不做详述User订UserRoleRoleUiurlDVrIDRolelDUserNanie：RolelDRoleNfnig2. 基于操作的权限设计这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如

2、下：但是如果直接使用上面的设计，会导致数据库中的以我们需要进一步设计提高效率，请看方案33. 基于角色和操作的权限设计UserAction这张表数据量非常大，所如上图所示，我们在添加了Role,和RoleAction表，这样子就可以减少 UserAction中的记录，并且使设计更灵活一点。但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色 是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工 权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。4.

3、 2,3组合的权限设计，其结构如下：UserActionuswirActioitXDHasPermi ssinA-VCO.RoleTimAct ionActi onNanieUserRoleRoleActionUserIDRolelDJActicnID我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的 优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRole和UserAction两张表中的记录判断权限。到这儿呢并不算完，有可能用户还会给

4、出这样的需求：对于某一种action所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需 要设计更复杂的权限机制。5. 对于同一种实体（资源）用户可以对一部分记录有权限，而对于另外一些记录没有权限的权限设计：ChannelIDHomeBescripti onUserI UserIDVstrKamtUserActionChannelUstrlD icti onlD ChiiknellB Hasf ermi esiilUserActionContcnUserIDrvActi onXDCc

5、ntentIDHasPermissi onActionActi orJDActiKescurceTypiContentIDN刘电Description对于这样的需求我们就需要对每一种不同的资源创建一张权限表，在上图中对Con te nt和Channel两种资源分别创建了 UserActionContent和UserActionChannel表用来定义用户 对某条记录是否有权限；这种设计是可以满足用户需求的但是不是很经济，UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记 录所有的记录的权限信息，有时候可能只是一种规则，比如说对于根C

6、hannel什么级别的人有权限；这时候呢我们就可以定义些规则来判断用户权限，下面就是这种设计。6.涉及资源，权限和规则的权限设计ChannelIDNameDescriptionActionRuleIDRuleTypeAssembly5UserUserIDUserNameAction实现业务系统中的用户权限管理设计篇B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的容户漱所叹访问用户的权限检测可以通过 客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整 的权限检测，那么一个一非法用户”很可能就能通过浏览器轻易访问到B/S系统中的

7、所有功能。因此B/S业务系统都需 要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经 授权的非娴户”将会将他们彻底的拒之门外一。下面就让我们一起了解一下如何设计可以满足大咅吩B/S系统中对 用户功7液限控制的权限系统。需求陈述不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。可以对“组进行权限分配。对于一个大企业的业务系统来说，如果萸求管理员为其下员工逐一分配系统操作 权限的话，罡件耗B寸且不够方便的事情。所叹，系统中就提出了对一组进行操作的槪念，将叔限一致的人员编 入同一组，然后对该组进行权限分权限管理系统应该

8、是可扩展的。它应该可咲加入到任何带有权限管理功能的系统中。就像是组件一样的可 叹披不断的重用，而不是每幵发一套管理系统，就藝针对权限管理部分进行重新开发。満足业务系统中的功能权限。传统业务系统中，存在看两种权限管理，其一是功能权限的管理，而另外一 种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。关于设计借助Noanweb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程咲及 数据库结构开始入手。为了实现需求，数据庫的设计可谓及其重要，无论是一组”操作的概念，还是整套权限管理系 统的亘用性，都在于数据偉的设计。我fiPt来分析一下数据库结

9、构：首先，actio儼（以下简称为“权限表”）,gorupmanager表（以下简称为“管理组表”）,以及master表（以下简称为“人员表，是三张实体花 它们依次记录着权限”的信息J官理组的信息和人员的信息。如下二筋表典艮表添加 WI除 更新超级管理员i 管理员 一般用户这三个表之间的关系是多对多的，一个叔限可能同时厲于多个管理组，一个管理组中也可能同时包含多个权限。同样的道理，一个人员可能同0寸厲于多个管理组，而一个管理组中也可能同时包含多个人员。如下图:丸枕限滾NNgr潘加IS级管理员iffl除一破用户张三李四王五由于这三张表之间存在看多对多的关系，那么它们之间的交互，最好使用另外两张表

10、来完成。而这两张表起看 映射的作用，分别llactiongroupT表（以下简称濒限映射表八mastergroup表（以下简称“人员映射 表前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图：s挪碱射希 奉加超级管世员 稍除超级管理员 添加-着理员 删除皆理员 更舫-一绘用户张三-超级借理克 张三管理员李四-超级借理员 李四-管理员 王五一躱芹户三四五张李王和管理组衷之间猬到了交互.“人员映身使人员哀薯管理吹之嘶了另外，还需要T长表来控制系统运行时左侧菜单中的权限分栏，也就是权限分栏表S如下图:grc简理廳or添加1剧除更篇1海加超令借理员 删除-超级管理员 海

11、加管理员 删除爸理员 更W用户妞级管理员 管理员 一般用户|张三超级管理员 张三-符理员 李四-超级爸理员 李四管理员 王五户张三 $13 王五权限分崔根抿上面的分析，我们进行敖抿阵结构设计，如下砂fJA11If XM I *占托汝甲杳看权限管理系纟糊抿表宇段论计为了能够进行良好的分析，我们将数抿産结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下 弼长映射衰的作用。一权限映射表如下團：苜先，我们来了解一下权限映射表与菅理组表以及权限衰之间的字段关联。actionactiomdAactionnweactioncolumxaction7actiongroupactloncoluMnac

12、ti oncolwm d ctio ncolximnnajneaction $roupi d mastri d mztmajT)4 createdategroupaanagerBast ergroupLcronpidj idgroupname/masteridigroupinfo/namemasteridgroxipidmftdArnAmomasterid2creatd$masternamecreatedaBasteridname password bdate truename sex birthday dept position position_desc office_phone mobi

13、le home_phone email a&sterid ft&stern&ne cre&ted&te看團中的红圈，先看gorupid字段木跌联，这种关联方式在实际数据库中的表现如下图:ctTon*masterid masternawe createdateacfeOcti onrsoftcti oncolumni dJet i oiTivi remote如阿中所示，管理组表中“超级管理员”的groupidi,那么权限映射表中gro叩id为啲权限也就是超级管理 员”所拥有的权限。使用groupid字段关麻，罡为了査到一个管理组能朔女行的权限有哪些。但这些权限的详纟陥鞋Inaction字段关畅查

14、削的。action字段相关联在数据库中的表现如下图:塩农tJcTiongrou中的敷据,位蚩是sq：ln理表rJroupBanager中的数扼idactionllcroupidfrowi d 1groupnwn1setupD超辺管理员2addn regroup12管理员3.ddntw group_x13一股用户4stlgroupinfo15stgroupino_i:16se t group inf o_e)117delgroup_ex1通过这种关联，才查询到权限映射表之中那些权限的详纟陥息。综合起来，我侮嗾能了一个管理组可叹执 行的权3艮有哪些，以及这些权限的详细信息是什么。或许你会冋，为什么

15、不使用actionid字段相关脈呢？因为：取限表中的i与段在经过多次储振庫操作之后可能会发生更改。取限映射表中仅仅记录看一个管理组可以执行的权限。一旦取限表中的id更改，那么权限映射表中的记录也就更改了。f 管理组可以执行的权限势必将出昔，这罡非常不希望的。考虑到上面的情况，所I次应该使用action字段相关联，因为：在权限表中，id可能发生变化，而action字段却罡在任何情况下也不可能发生变化的。取限映射表中记录的acho谆段也就不会变。 f管理组可叹执行的权限就不会岀昔了。二人员映射表如下图:我们来了解一下人员映射表与管理组表汰及人员表之间的字段关联，如下團:人员表group group

16、nanieCroupinfo masteri dntztrnnecre&tftd&te 2睞熬希password bdt truenanesex birthday dept position posi tion.desc ofict_phon mobile home_phone eaail masterid masternawe erg tdQ看團中的红圈部分，先看groupid?段关联，这种关联方式在数抿库中的表现如下图:如團，超级管理员组的groupid为1,我们再看人员映射表，adminJI于超级管理员组，而admlmstratorJI于 超级管浬员组，同时也属于管理员组。使用这种关联方

17、式，是为了查到一个管理组中的人员有谁。和上面一程，人员的i羊细信息是Itid字段（人员映 射表中是mastend字段）关麻査询到的。|俾段（人员映射表中是masten時段关麻表现在数据库中的形式如下图:actioaidpd_acti onnanelectionactioncolunoiid Igroupii|actioni aster! dviewraodeLasternajne|l|createdate一个人员可能同时届于多个管理组S如图中，administrate）戟同时属于两个管理组爲所儿在人员映射表 中关于administrate）啲记录就会是两条。这种关联方式才查询到菅理组中人员的详

18、细信息有哪些。综合起来，才可以知道一个管理组中的人员有谁，叹 及这个人员的详细信息。再结合上面谈到的权限表和权限映射表，就实现了需求中的组操作，如下图:叵pass oi*d bdate truenawe sex birthday dopt position posi tion_desc office_phone mobile hone_phone email nastrid ntstrnan cre4tedate其实，管理组表中仅仅记录看组的基本信創 如名称，组id等等。至于一个组中人员的i羊细信息，叹及该组能 够期亍的权限的详细信息，都记录在人员表和权限衰中。两张映射表才亘正记录看一个组有哪

19、些人员，能够执行 哪些戎限。通过两张映射表的衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组”操作。培表*actioncoluMi中的数据我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下團:action】d权限初始化安装 添加管理姐 添加管建组执行 设置笛理迫权限 设置管翟组权限! i 设置管湮爼权限J 删除筲理追 查看営理员分组 吏看管理爼成员 设置菩理员权限I 咛】oncolsrud-CDacti oncolunnnaml营理权限新讯首理个人设置acfiR factioiiidactiormwnlctioncolufuii ction viewmode

20、acSgiacti oncolmii cti oncolsnnso两张表使用了actioncolumnid字段相关联,这种关脈方式在数抿库中的表现如下图:険表玉虽中的数据,侍&2设盖管理昂权限 游加筲理员 忝加言理员执行I2 更改背理员密码I 2 更改管耀员言2 更改营理员巒玛乍2 更改管理员信息2i2219 更改管邊员倍息制220 更改管建员信息21 删除指定筲理员 如團所示，通过这种关联方式，我们可以非常清时的看到权限表中的权限届于哪个分栏。现在，数据库结构已经很淆術了，分配权限的功能以及组操作都已经实现。下面我们再来分析一下需求中提 到 的X干加 覘苦押玄绪的宙田.对件么快用这扌咳聒库设

21、Tt力式珞躍起米旳糸汛DJ臥更用呢7三张实体表中记录看系统中的三个决定性元素。“权限，组和人。而这三种元素可以任意添加，彼此之 间不受影响。无论是那种类型的业务系统，这三个决定性元素是不会变的，也就童味看结构上不会变，而变 的仅仅是数据。两张映射表中记录着三个元素之间的关系。但这些关系完全罡人为刨建的，需要变化的时候，只罡对数振 偉中的记录逬行操作，无需改动结构。权限分栏表中记录看系统使用时显示的分栏。无论定要添加分栏，修改分栏还是减少分栏，也只不过是操 作记录而已。综上所述，这样设计数據庫，系统是完全可以重用的，并且经受得住“变更”考验的。总结：止匕套系统的重点在于，三张实体表牢牢地拥住了系

22、统的核心成分，而两张映射表完美地映射出三张实体表之 间的交互。其难点在于，理解映射衰的工作，它记录看关系，并且实现了组操作的概念。而系统总体的设计是本 看可以在不同的MIS系统中”重用”来満足不同系统的功能权限设置。权限青理系统数抿表的字段设计下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：亏 action :表action 表:字段名称数据类型说囲9actiomd自动胸号自増长idacti onnom*动作名称actioncolvmnid动作分栏导（映射acti oncol）action动作字符串vi emod是否可见1actioncoluBn :表字段名称数据笑型说明17a

23、ctioncolumnid数字目增长】dactioncolunnname文本动作分栏名称actiongroup：二)actiongroup :表回字段名称数爲类型说明id自増长、daction数字动作名旋（蝕射到cUon表）groupid数字动作所SlSiK映射到mastergroup )masterid创连者Mmastername创逹者名称crea百期/时间创逢时间区actioncolumn中记录看动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分 栏，毋添加一个分栏，该表中的记录就会増加一条相对应的，左侧菜单栏中也会新増机一个栏。actiongroup记录着动作所在的

24、组。二 sroupanager :表字段名称p*oupnamp*oupino nasteridgrcupman ager表:_ nasternane 卜 createdate管理俎名称 昔理组信息 创運者讹 创建者名称 组创建时、引groupmanage嚥记录着管理组的扌跌信息，每添加一个管理组，这里的记录就会増加一条。flMut erer01V -表bi字段容葩数弱类型n说明klid数字自増栓记mas ter id數字管理员i d （映射盘k a.s t皓表）1noma立本管理曷名稀poupi i遊字管理担i d（映肘到厚匹p表）mtstffi d2戲宇催改音诃m&stArxham*玄本修改

25、音毛稀mastergroup:er4.leda.tt日期/时间修改时间mastergroup记录着菅理员所在的管理组，由于一窖管理员可能同同时属于塞个组，所该表中关于1 管理员的记录可能有爹条.nnaster：? idname p*E sward bdate t rutnamemas t en d字啟名称数露芫型:口 ster :表T数子本字卿本亲船本女ptpotk.tidipositi*n_dfrs亡offiefejphoiiia niobilhdmfejhoneenailHXbirhdsycreatedale目増长讨 苜理员名祢 管理岗密码 创建时间 耳实姓名 性别 生日 所届部门诫务说明 办