权限设计方案.docx
《权限设计方案.docx》由会员分享,可在线阅读,更多相关《权限设计方案.docx(14页珍藏版)》请在冰豆网上搜索。
![权限设计方案.docx](https://file1.bdocx.com/fileroot1/2022-12/16/2273f45c-fd82-4593-8c54-192361ffc82c/2273f45c-fd82-4593-8c54-192361ffc82c1.gif)
权限设计方案
权限管理设计一
∙博客分类:
∙设计
设计模式数据结构
应用程序权限设计
我们在开发系统的时候,经常会遇到系统需要权限控制,而权限的控制程度不同有不同的设计方案。
1.基于角色的权限设计
这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,所以微软就设计出这种方案的通用做法,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述
2.基于操作的权限设计
这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:
但是如果直接使用上面的设计,会导致数据库中的UserAction这张表数据量非常大,所以我们需要进一步设计提高效率,请看方案3
3.基于角色和操作的权限设计
如上图所示,我们在添加了Role,和RoleAction表,这样子就可以减少UserAction中的记录,并且使设计更灵活一点。
但是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,但是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。
4.2,3组合的权限设计,其结构如下:
我们可以看到在上图中添加了UserAction表,使用此表来添加特殊用户的权限,改表中有一个字段HasPermission可以决定用户是否有某种操作的权限,改表中记录的权限的优先级要高于UserRole中记录的用户权限。
这样在应用程序中我们就需要通过UserRole和UserAction两张表中的记录判断权限。
到这儿呢并不算完,有可能用户还会给出这样的需求:
对于某一种action所操作的对象某一些记录会有权限,而对于其他的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有修改的权限,而对于另外一些频道没有修改的权限,这时候我们需要设计更复杂的权限机制。
5.对于同一种实体(资源)用户可以对一部分记录有权限,而对于另外一些记录没有权限的权限设计:
对于这样的需求我们就需要对每一种不同的资源创建一张权限表,在上图中对Content和Channel两种资源分别创建了UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限;这种设计是可以满足用户需求的但是不是很经济,UserActionChannel和UserActionContent中的记录会很多,而在实际的应用中并非需要记录所有的记录的权限信息,有时候可能只是一种规则,比如说对于根Channel什么级别的人有权限;这时候呢我们就可以定义些规则来判断用户权限,下面就是这种设计。
6.涉及资源,权限和规则的权限设计
兰亭序
永和九年,岁在癸丑,暮春之初,会于会稽山阴之兰亭,修禊事也。
群贤毕至,少长咸集。
此地有崇山峻岭,茂林修竹;又有清流激湍,映带左右,引以为流觞曲水,列坐其次。
虽无丝竹管弦之盛,一觞一咏,亦足以畅叙幽情。
是日也,天朗气清,惠风和畅,仰观宇宙之大,俯察品类之盛,所以游目骋怀,足以极视听之娱,信可乐也。
夫人之相与,俯仰一世,或取诸怀抱,晤言一室之内;或因寄所托,放浪形骸之外。
虽取舍万殊,静躁不同,当其欣于所遇,暂得于己,快然自足,不知老之将至。
及其所之既倦,情随事迁,感慨系之矣。
向之所欣,俯仰之间,已为陈迹,犹不能不以之兴怀。
况修短随化,终期于尽。
古人云:
“死生亦大矣。
”岂不痛哉!
每览昔人兴感之由,若合一契,未尝不临文嗟悼,不能喻之于怀。
固知一死生为虚诞,齐彭殇为妄作。
后之视今,亦犹今之视昔。
悲夫!
故列叙时人,录其所述,虽世殊事异,所以兴怀,其致一也。
后之览者,亦将有感于斯文。