应用程序权限设计

我们在开发系统的时候,经常会遇到系统需要权限控制,而权限的控制程度不同有不同的设计方案。

 

1.       基于角色的权限设计

这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,所以微软就设计出这种方案的通用做法,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述
应用程序权限设计

2.       基于操作的权限设计

这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:

应用程序权限设计
但是如果直接使用上面的设计,会导致数据库中的
UserAction这张表数据量非常大,所以我们需要进一步设计提高效率,请看方案3

 

3.       基于角色和操作的权限设计

应用程序权限设计
如上图所示,我们在添加了
Role,和RoleAction表,这样子就可以减少UserAction中的记录,并且使设计更灵活一点。

但是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,但是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。

 

4.       2,3组合的权限设计,其结构如下:

应用程序权限设计
我们可以看到在上图中添加了
UserAction表,使用此表来添加特殊用户的权限,改表中有一个字段HasPermission可以决定用户是否有某种操作的权限,改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRoleUserAction两张表中的记录判断权限。

到这儿呢并不算完,有可能用户还会给出这样的需求:对于某一种action所操作的对象某一些记录会有权限,而对于其他的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有修改的权限,而对于另外一些频道没有修改的权限,这时候我们需要设计更复杂的权限机制。

 

5.       对于同一种实体(资源)用户可以对一部分记录有权限,而对于另外一些记录没有权限的权限设计:

应用程序权限设计
对于这样的需求我们就需要对每一种不同的资源创建一张权限表,在上图中对
ContentChannel两种资源分别创建了UserActionContentUserActionChannel表用来定义用户对某条记录是否有权限;这种设计是可以满足用户需求的但是不是很经济,UserActionChannelUserActionContent中的记录会很多,而在实际的应用中并非需要记录所有的记录的权限信息,有时候可能只是一种规则,比如说对于根Channel什么级别的人有权限;这时候呢我们就可以定义些规则来判断用户权限,下面就是这种设计。

 

6.       涉及资源,权限和规则的权限设计

应用程序权限设计
在这种设计下角色的概念已经没有了,只需要
Rule在程序中的类中定义用户是否有操作某种对象的权限。

以上只是分析思路,如果有不对的地方,请大家指正。

文章来源于互联网:
应用程序权限设计

技术交流Q群: 1012481075 群内有各种流行书籍资料
文章后续会在公众号更新,微信搜索 OneByOneDotNet 即可关注。
你的一分鼓励,我的十分动力,点赞免费,感恩回馈。喜欢就点赞评论吧,双击6666~
本网站(网站地址)刊载的所有内容,包括文字、图片、音频、视频、软件、程序、以及网页版式设计等均在网上搜集。
访问者可将本网站提供的内容或服务用于个人学习、研究或欣赏,以及其他非商业性或非盈利性用途,但同时应遵守著作权法及其他相关法律的规定,不得侵犯本网站及相关权利人的合法权利。
除此以外,将本网站任何内容或服务用于其他用途时,须征得本网站及相关权利人的书面许可,并支付报酬.
本网站内容原作者如不愿意在本网站刊登内容,请及时通知本站,予以删除.
转载请注明出处
作者昵称:OneByOneDotNet
作者链接:https://onebyone.icu/user/1
网站标题:DotNetOneByOne
网站地址:https://onebyone.icu
文章标题:应用程序权限设计
文章链接:https://onebyone.icu/archives/2658
原文出处:
原文链接:
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

WeChat
WeChat
QQ
QQ
返回顶部