精华内容
下载资源
问答
  • 系统权限设计

    2012-11-10 20:20:16
    但是这里我不是想设计一个权限管理系统,网上的设计方案太多了,可以说每个开发人员都有自己的开发权限管理系统的想法和思路。 C#:  好吧,先从最简单开始,定义一个用户(User)类,如下。 1 c
    大部分系统都有权限系统。一般来说,它能管控人员对某个否页面的访问;对某些字段、控件可见或者不可见。对gridview中的数据是否可删除、可添加、可新增等等。大部分人都把权限作为一个子系统独立出来。但是这里我不是想设计一个权限管理系统,网上的设计方案太多了,可以说每个开发人员都有自己的开发权限管理系统的想法和思路。
    C#:
       好吧,先从最简单开始,定义一个用户(User)类,如下。
    1 class User
    2 {
    3     bool CanDelete;
    4    bool CanRead;
    5     bool CanWrite;
    6    bool CanModify;
    7     bool CanCreate;
    8 }
        这里设计5个属性来管控用户的权限。我发现这样虽然很直观,但是不宜扩张。我们将权限独立出来,在看下面代码:
    1 enum PermissionTypes : int
    2     {
    3         None =0,
    4         Read =1,
    5         Write =2,
    6         Modify =4,
    7         Delete =8,
    8         Create =16,
    9         All = Read | Write | Modify | Delete | Create
    10     }
    11 class User
    12     {
    13        public PermissionTypes Permissi** = PermissionTypes.None;
    14     }



        我们先试用一下,你就能感觉到神奇之处:

    1 //创建一个用户

    2 User admin =new User();
    3 admin.Permissi** = PermissionTypes.Read
    4     | PermissionTypes.Write
    5     | PermissionTypes.Delete;
    6

    7 //验证权限

    8 bool canRead = ((PermissionTypes.Read & admin.Permissi**) == PermissionTypes.Read);
    9 bool canWrite = ((PermissionTypes.Write & admin.Permissi**) == PermissionTypes.Write);
    10bool canCreate = ((PermissionTypes.Create & admin.Permissi**) == PermissionTypes.Create);
    11
    12
    //查看结果
    13 C**ole.WriteLine(canRead); //true
    14 C**ole.WriteLine(canWrite); //true
    15 C**ole.WriteLine(canCreate); //false
    16 
        利用了'|'和'&'两个操作。但是这样看起来很是很别捏,初始化权限和验证权限用了一长串'|'和'&'运算的代码。很不直观。我在System.Enum中扩展一些方法供你调用,代码如下。

    1 //是否存在权限
    2 public static bool Has<T>(this System.Enum type, T value)
    3         {
    4        try
    5             {
    6               return (((int)(object)type & (int)(object)value) == (int)(object)value);
    7             }
    8        catch
    9             {
    10              return false;
    11            }
    12         }

    13 //判断权限

    14 public static bool Is<T>(this System.Enum type, T value)
    15         {
    16       try
    17             {
    18               return (int)(object)type == (int)(object)value;
    19             }
    20       catch
    21             {
    22               return  false;
    23             }
    24         }
    25

    //添加权限
    26  public  static T Add<T>(this System.Enum type, T value)
    27         {
    28           try
    29             {
    30               return (T)(object)(((int)(object)type | (int)(object)value));
    31             }
    32           catch (Exception ex)
    33             {
    34               throw new ArgumentException(
    35               string.Format(
    36               "不能添加类型 '{0}'",
    37               typeof(T).Name
    38                         ), ex);
    39             }
    40         }
    41
    42 //移除权限
    43 public static T Remove<T>(this System.Enum type, T value)
    44         {
    45        try
    46             {
    47               return (T)(object)(((int)(object)type & ~(int)(object)value));
    48             }
    49        catch (Exception ex)
    50             {
    51               throw new ArgumentException(
    52                           string.Format(
    53                           "不能移除类型 '{0}'",
    54                           typeof(T).Name
    55       
    展开全文
  • OA系统权限设计数据库实现.zip OA系统权限设计数据库实现.zip
  • 通用的管理系统权限设计 原文:通用的管理系统权限设计在以前的工作中,我常常会遇到一些系统管理权限的问题,常常是一种系统一种管理方式,很浪费时间和精力,后来我根据Windows的文件权限管理方式想...
    原文:通用的管理系统权限设计

    在以前的工作中,我常常会遇到一些系统管理权限的问题,常常是一种系统一种管理方式,很浪费时间和精力,后来我根据Windows的文件权限管理方式想了一种相似流程的控制方式,具体流程如下:

    13.jpg

    将系统的功能页面加入到模块中,并加入权限限制造,权限可以灵活设置,加入多种权限,对于用户可单独设置权限,也可以给角色设置权限,配置流程和Windows权里的方式差不多,系统代码正在编写中,完成之后将开源贡献给大家,下面是表结构及关系

    14.jpeg

    关系图

    12.jpg

    posted on 2018-10-16 22:24 NET未来之路 阅读(...) 评论(...) 编辑 收藏

    转载于:https://www.cnblogs.com/lonelyxmas/p/9801114.html

    展开全文
  • 点击上方“xy的技术圈”,选择“设为星标”认真写文章,用心做分享。微信公众号:xy的技术圈个人网站:yasinshaw.com正文在上篇文章《系统权限设计 - 基本概念和思路》中,介绍了...

    点击上方“xy的技术圈”,选择“设为星标

    认真写文章,用心做分享。

    微信公众号:xy的技术圈

    个人网站:yasinshaw.com

    正文

    在上篇文章《系统权限设计 - 基本概念和思路》中,介绍了我们在做权限设计的时候需要注意的一些点。其中有两点比较关键,这里再次提一下:

    • 粒度:粒度很难把握,推荐以一个基本的“业务操作”为粒度;

    • 区分Access与Validation:其中,Access与数据无关,可以在网关那一层就挡住;Validation与数据有关,可以在下游Service写代码来做。

    下面将从后端到前端来介绍整个权限设计的推荐实践细节。

    后端实现细节

    分别从Access和Validation的实现角度来介绍。

    Access怎么做?

    Access就是一个个写死的权限。比如在Spring Security中,它是一个个字符串。你可以把它写死在Config文件里,也可以存在数据库里。

    一般来讲,存在数据库里更灵活,如果配上一个管理界面,也比较容易管理。这里简单介绍一下存在数据库里如何做。以Spring Security为例,可以使用自定义的Bean拦截所有请求。在Bean里面可以取到request的URL等信息,然后去查数据库或session或解析JWT Token等方式取得当前用户拥有的权限,再去进行匹配。

    Validation怎么做?

    Validation需要验证数据当前的状态等信息是否满足条件。甚至有时候,不同的角色对同一个状态,也有不一样的权限。Validation在设计和使用的时候,可以考虑以下四个因素:多个角色如何判断权限、短路设计、消除角色、白名单 or 黑名单。下面分别详细介绍这几个因素,然后给出一个推荐的通用Validator代码实现。

    多个角色如何判断权限

    一般来说,在稍微复杂一点的权限管理需求中,一个人往往有多个角色。那如何判断这个人是否对当前这个操作有权限呢?

    按照一般来逻辑来讲,当前用户只要有一个角色对这个操作有权限,我们就认为当前用户对这个操作有权限。

    短路设计

    因为Validation需要去查询数据。在微服务的环境下,它甚至有时候需要call其它API。前面提到,只要有一个角色对这个操作有权限,我们就可以认为当前这个用户对这个操作有权限。那后续的判断逻辑就可以不走了,程序做成短路设计,有利于减少数据查询和API调用,提升性能。

    消除角色

    我们在写Validation代码的时候,来自业务方的叙述,可能与角色相关。比如某写作平台,在发布文章后,作者不能再修改文章,但网站的编辑可以。我们用伪代码表示这个validation的逻辑:

    这样我们就把“角色”写死到了代码里。假如以后有另一种角色也可以修改文章,比如网络安全审核员。那就需要改代码,重新发布。这样就很不灵活。

    我们可以尝试消除代码中的“角色”,而是改成权限。比如,我们赋予editor这种角色一个叫edit_published_article的权限,这样我们的代码就可以写成这样:

    这样的话,我们只需要把这个权限赋予给新加的角色,它就可以进行这个操作了。无需修改代码。

    那什么时候不能消除角色呢?

    但validation一定可以完全消除角色的吗?)不是的。如果你的系统业务,会把角色的id放到业务数据库里,就不能在validation中消除角色

    比如我们在上一篇文章中举的例子:如果当前用户是老师,那他可以查看自己课程的试卷。如果是教务主任,可以查看当前年级的所有试卷。这个时候,需要根据不同的角色,去不同的表拿不同的数据。所以“角色”一定会写到validation代码中。这是无法避免的。

    但是大多数业务,我们是可以消除角色的。消除角色带来的好处也显而易见,而唯一的缺点是会增加很多权限,使得管理权限变得复杂一些。通常是对应到枚举上,一个枚举的value就会对应一个权限。不过我们可以通过添加“权限组”的概念来解决这个问题,后文会介绍权限组。

    通用Validator代码实现

    下面给出一个基于Java代码的通用Validator实现及其用法。读者也可以根据自己的需要进行增强:

    前端实现细节

    处于对系统安全性的要求,我们在后端是必须要做权限控制的。而前端有时候也需要做相应的权限控制,是希望能在UI上给用户更好的体验。比如,不该当前用户看到的页面,就不会出现在左边的导航栏。用户不能点击的按钮,就应该隐藏或者置灰。

    页面权限控制

    页面显示通常是比较粗粒度的UI控制了。如果角色及其权限相对稳定,可以死在前端配置里,这样开发成本比较低。

    而如果角色及其权限容易变化,可以后端返回路由配置,这样就实现了用户,角色,路由的动态配置,全部统一管理。

    具体实现细节大家可以参考掘金上的这篇文章:《如何优雅的在 vue 中添加权限控制》。

    组件权限控制

    组件权限控制是一种比较细粒度的UI控制。具体来讲,有两个方案:

    • 前端写验证逻辑;

    • 所有逻辑都在后端,后端返回Flag,前端根据这个Flag判断。

    这两种方案各有优劣,下面我们来讨论一下。

    前端写验证逻辑

    如果是前端写验证逻辑,就是前端通过已有的数据,去判断组件是否可以显示或者可以操作。比如很多时候,某个按钮可不可以点击,是根据用户的角色,或者当前数据的状态来判断的。在一个表格页面,用户的角色和当前数据都是已知的。所以前端只需要写一个与后端一模一样的逻辑,就可以控制了。

    这就会带来一个问题。比如我们删除一个数据,会根据这个数据的状态来做验权。后端肯定是需要写这个验证逻辑的,如果前端再写一份,那就会在前后端各自维护一段相同功能的逻辑。后期如果要修改逻辑的话,就需要前后端同时修改,造成代码维护上的不便。

    另外一个问题是,如果前后端理解不一致,可能就会造成前端按钮看起来可以点击,但点击后,后端报了403错误。这可能是由于程序BUG,但如果前后端分离开来,就加大了在开发过程中,这种BUG产生的几率,降低开发效率。

    还有一种情况是不适用于在前端写验证逻辑的。就是有些比较复杂的Validation,需要查其它数据库甚至是其它服务的数据,这种情况就不适合在前端做,不然可能要多Call好几个API。

    后端返回Flag

    如果是后端返回Flag,就可以解决上面提到的两个问题。这个时候,验证逻辑全部放到了后端,后端在“读”数据的时候,和真正进行业务操作“写”数据的时候,可以复用同一个Validation的逻辑。

    后端返回Flag就是完美的解决方案吗?不是的。它同样会有两个问题。

    第一个是对response结构的侵入。我们会在response里面加一个甚至是多个Flag,而这些Flag其实是跟业务数据是无关的。这里比较建议的是用偏业务的叫法来命名Flag,而不是偏前端UI的叫法。比如,叫canDeleteXXX比叫showXXXButton要好。

    另一个问题是,有些操作可能只需要Access控制,不需要Validation。这个时候,其实后端也没有复用任何代码,因为进行“写”操作的时候,会在网关那一层通过Access验证权限,进来了没有走任何Validation。所以这种情况下,单纯为了加Flag,在读数据的时候去写逻辑判断Flag,反而不好。

    推荐方案

    对于一个操作的权限控制,通常有两种情况:

    • 只需要Access,

    • 需要Access + Validation

    综上两种实现的比较,笔者推荐的方案是:后端返回的Flag只与Validation有关,前端写死的代码里只与Access有关。

    下面是以Vue为例的一个示例代码:

    当然,不同团队可以根据自己的实际情况进行取舍和改进。

    用户组与权限组

    有时候我们可能会根据业务需求,对RBAC模型进行一定的增强。比如用户组、权限组等。

    用户组

    如果用户太多,对一个一个用户管理角色可能会比较困难。这个时候我们可以抽象出“用户组”的概念。相当于公司的“部门”。这样就可以对一组用户来管理角色,可以让管理更加方便。

    权限组

    在前面我们提到,有时候在Validation中,可以“消除角色”。这带来的代价就是会根据数据的状态创建不同的权限,使得权限增多。比如高中有3个年级,我们想分别对这三个年级有不同的权限控制,就得创建三个权限。

    另一种情况是Access对API的关系。在上篇文章中,笔者推荐的是以“业务操作”为粒度。比如发朋友圈,假设有三个步骤:上传图片,获取当前位置,确认发布。我们其实只需要一个发朋友圈的Access,而不是三个Access。但这个Access其实对应的是三个API,而每个API又可能不止一个Access。比如上传文件,我们在聊天的时候也会用到这个API。所以Access与API是多对多的关系。

    权限多了,就不容易管理。所以可以抽象出一个权限组的概念,来更好地管理权限。

    当然了,增加用户组和权限组都会带来一定的复杂性,使现有的权限模型变得更加复杂。所以再次提醒大家,在做权限设计的时候一定要遵循“够用就行”的原则,切勿过度设计

    以上两篇文章是笔者对权限系统设计的理解和总结。如果读者有任何疑惑的地方,或理解不一致的地方。欢迎留言讨论~

    END

    推荐阅读

    ↓↓↓ 点击"阅读原文" 去【评论】吧

    展开全文
  • DH ERP系统权限设计

    2020-04-23 19:06:01
    一、系统权限定义 1、功能权限 定义:功能权限指的是用户登陆系统后,所持有的功能权限因子下的权限,而展示对应系统中各个菜单页面、操作功能等。功能权限设置分: 【角色授权】 【用户授权】 2、数据权限 ...

    一、系统权限定义

    1、功能权限

    定义:功能权限指的是用户登陆系统后,所持有的功能权限因子下的权限,而展示对应系统中各个菜单页面、操作功能等。功能权限设置分:

    • 【角色授权】
    • 【用户授权】
    2、数据权限

    定义:数据权限指的是用户登录系统后,所持有的数据权限因子下的权限,而展示对应的系统数据。数据权限设置分:

    • 【角色授权】
    • 【用户授权】

    二、系统权限实现

    根据功能权限、数据权限的定义:

    1. 对于系统中某个菜单页面,如果登陆用户持有功能权限,则允许进入浏览该菜单页面(),在该菜单页面中,用户持有某个操作功能权限,则允许用户操作当前页面该用户所持有的数据权限展示出来的数据(),从而达到控制用户对系统的读写功能。
    2. 根据角色设置好【功能权限】后,当系统中某个用户持有该角色:
    • 角色无法满足用户所需权限(角色权限范围大于或小于用户所需权限),调整用户【角色权限】范围能解决,如角色定义时范围过大或过小。
    • 角色定义合理并且满足大部分用户,个别用户权限无法满足,则针对个别用户进行【用户权限】设置,此时会产生一个冲突:如图
      在这里插入图片描述
      A、【角色权限】设置范围过大:用户只需求其中一部分权限时,针对用户设置的个人权限,此时用户的正确权限应该是【角色权限】与个人设置的【用户权限】的交集部分。
      B、【角色权限】不够:用户所需的部分权限在角色权限之外时,针对用户设置【用户权限】,此时用户的正确权限应该是用户设置的【用户权限】。
      而冲突点是:系统在对角色、用户设置好权限后,这两份权限如何合并成用户正确的权限。系统是无法比较角色、个人所设置的权限范围大小,一般的处理方法是要么取两个集合的交集,要么取两集合的并集,但得到的结果都不是理想的。
      解决方案:
      系统中最终只以设置的【用户权限】为准,在设置用户为某个角色时,只是将该角色所持有的权限复制到个人设置中,在此基础上,根据用户需求,对所持权限因子进行增删。因为去掉了【角色权限】的影响,最终得到的权限一定是正确的。
    1. 以设置【用户权限】为准的情况下,如果只是功能权限、单一的数据权限因子,则完美解决以上冲突。但是当数据权限因子存在多个,并且每个因子相互影响时,则会产生新的冲突。首先,因为去掉了【角色权限】的影响,所有的数据权限因子就处在同一个优先级上,如图:
      在这里插入图片描述
      因为各个数据权限因子同时作用于某一份数据时,取各个因子的并集会产生数据权限越界,取各个权限因子的交集,则会导致缺少数据。
      解决方案:
      既然单纯的通过各个数据权限因子取交集或并集无法解决问题,那就通过人为选定数据范围。首先保证每个数据权限因子只影响因子本身的数据,举个例子:
      设一个数据权限因子:供应商。则分配给用户的供应商权限,在供应商列表数据、下拉列表中限制出来供应商,而在供应商产品中因为与【产品类目】这一个权限因子同时作用于该列表数据,作为供应商用户,他需要看到他持有的供应商供应的所有数据,【产品类目】的限制就应该去掉;而作为采购员(或其他以【产品类目】权限为主)用户则刚好相反。因为系统权限设计一开始就弱化角色,强化用户权限,此时根据用户的侧重工作(是供应商用户还是采购员用户),在功能菜单权限中设定【数据范围】获取方式:
    • 所有因子交集
    • 所有因子并集
    • 指定因子
    展开全文
  • 系统权限设计思路

    千次阅读 2018-05-03 17:39:53
    权限系统通常包括如下基本元素:用户、角色、权限、资源、操作。 角色分类:总经理、部长、员工。(在实际中一个用户可能存在多个角色,这就要考虑到权限累加处理) 权限分类:如”员工考勤权限”、”审核权限”...
  • 基于AOP的大赛信息管理系统权限设计与管理
  • 系统权限设计说明文档

    千次阅读 2017-06-23 17:10:05
    权限设计方案-技术实现说明文档1. 新老系统权限区别 权限实现方式老系统使用shiro拦截器实现,新系统改变spring Interceptor,系统更为轻量,更为灵活。 菜单配置,老系统使用数据库存储的方式,新系统改变xml配置在...
  • 后台管理系统权限设计

    千次阅读 2018-06-19 23:06:24
    权限管理
  • java web 系统权限设计 源码

    热门讨论 2012-11-22 15:44:01
    权限系统源码【含文档】,很具有参考价值,推荐给大家。
  • 系统权限设计详解.doc

    2011-08-10 09:49:37
    • 不同职责的人员,对于系统操作的权限应该是不同的。可以对“组”进行权限分配。 • 对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中...
  • 系统权限设计与实现入门

    千次阅读 2017-07-01 17:58:19
    本来是想结合一下网上的文章经验来整理一下公司内部交流所分享的一些有关于权限设计与实现的解析与思路。...不同体量的系统,有不同的权限设计,那么如何对当下需求与未来规划做一番取舍,着实考验权限架构者的水平。
  • 如何做系统权限设计[摘录]

    千次阅读 2010-08-15 01:05:00
    系统权限设计大概有这几种模式: 用户+组+角色+权限 用户+组+权限 用户+角色+权限 用户+权限
  • 系统权限设计 1.多系统基于角色的权限设计 这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就...
  • 有关权限方面的一些想法和最近项目中的一些探索过程。 我们主要想解决一下问题...4.如何进行合理的表设计。 5.安全框架。 1.什么是权限 在很多与开发者也好,与客户也好,沟通的过程中我们很多次提到了权限,但是...
  • 由于游戏公司有不同的发行商,公司希望平台(图中的我)给每个发行商负责人独立的管理权限并由由他们各自管理各自的用户(就像上图中的关系。这种树型关系各位熟悉公司管理体系自然也能明白^_^)。 那么他们能在...
  • 点击上方“xy的技术圈”,选择“设为星标”认真写文章,用心做分享。微信公众号:xy的技术圈个人网站:yasinshaw.com正文权限系统设计几乎是每个系统都必需的模块,最近对系统的权...
  • 软件系统权限设计参考

    千次阅读 2018-05-05 17:37:30
    Role-Based Access Control: ExplainedRole-based access control (RBAC) normalizes access to functions and data through user roles rather than only users. User access is based on the definition of the ro...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,624
精华内容 6,249
关键字:

系统权限设计