zoukankan      html  css  js  c++  java
  • 后台权限管理,看这篇就够了

    转载至:http://www.sohu.com/a/340431910_695183

    产品经理在思考产品架构的过程中,必须要有业务流程的参与。通过业务流,常常会抽象出对产品有诉求的多个角色,再依据角色的特性去梳理使用场景并设计需求。

    当角色之间的使用场景不冲突,不需要隔离时,我们会综合考虑这些角色的使用场景来设计解决方案。比如QQ音乐同时需要为听歌和听电台的用户提供所有的功能需求。

    当这些角色的使用场景完全不重叠、流程对立时,我们会设计完全独立的两套系统,如微店卖家端和买家端;

    除了上面两种情况,在toB产品中,基于产品流程和信息安全等多符合因素考虑, 各个角色的使用场景是部分通用,部分隔离的,这时候就需要引入“权限系统”了。

    涉及到权限的问题往往是都是复杂的问题,在系统权限控制方面,我们经常会参照现成的案例来设计自己的权限控制,以下就是John所总结最常见的四种权限控制的方法。

    一、控制系统的帐号及登录

    1. 帐号的定义

    基本上所有的互联网产品,无论是移动端、PC端、C端或B端产品,登录都需要一个账号。只是对于C端的产品,都是用户自己注册即可。

    而对于后台产品而言,是需要公司内部人员去创建账号的。而这个账号就是一把钥匙,我们通过控制账号所具备的权限,进而控制这个员工的所操作区域。

    2. 帐号的层级:企业(管理员)帐号、普通帐号

    公司的实际运营人,他应该掌握最核心、权限最大的企业帐号,所以也可以称为“管理员帐号”俗称admin账号,其他都为普通帐号。

    在实际系统中的核心业务步骤如下:

    • 企业搭建系统时,默认会用admin作为系统账号的最高权限。下级可以创建企业账号(依托于权限)。

    • 在部署培训阶段,可指导企业账号持有人创建一个或多个普通账号(可是给其帐号授权管理员角色),后续配置即由管理员账号进行。

    (魅族的小伙伴可以说下,魅族论坛账号为“J.Wong”是不是admin的权限。哈哈哈哈)

    在用户状态上加状态控制,可用的用户就可以登录系统,禁用、停用的就无法登录。

    二、角色管理角色

    往往是基于业务管理需求而预先在系统中设定好的固定标签,每个角色对应明确的系统权限,他是一个集合的概念,是众多最小权限颗粒的组成。我们通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。

    其所拥有的系统权限一般不会随意更改,并且角色也不会随着用户的被添加和被移除而进行改变,相较于用户管理而言更加稳定。

    而引入“角色”概念后,用户与角色之间的关系链是怎么样的?这儿引用一个模型:RBAC模型(已经被大家写文章用坏了,可能有些小伙伴还是懵逼),John这边贴上百度百科解释下:

    基于角色的权限访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到广泛的关注。在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

    简单点一句话说下:Who(权限的拥有者或主体)对What/Which(权限针对的对象或资源)进行How(权限针对的对象或资源)操作。

    上图示意为:用户与角色可为多对一或多对多的关系,当一个用户的角色为多对多时,当前用户的权限是多个角色的并集。

    此时只需要为角色赋予权限,能够大大减轻管理负担,同时将用户与权限解耦,提供更大的灵活性。

    由于随着公司扩大角色的增多,试想如果用户量上万,新增一个角色时,可能需要为大量用户都分配一遍新的角色,工程量仍然巨大,此时即可以引入用户组的概念:如果部分用户的使用场景是相对一致和基础的,我们可以把这些用户打包成一个组,基于这个组的对象进行角色和权限的赋予。

    同理如果权限较多时也会存在一样的问题,处理方式是引入权限组的概念,将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的,所以实际应用中对权限组的使用较少。

    用一个页面例子来解释下:

    (用户组)

    (用户管理)

    (用户权限&权限组)

    三、控制功能权限(案例)

    功能权限定义:为可见、可以操作的功能范围。例如:某一部分目录,或者某个页面里的各种操作。

    1. 目录管理模块

    类型分为2种:目录、操作。

    在目录上加权限控制,有权限的就可以访问对应模块。

    在业务模块的功能按钮上加权限控制,最小粒度的控制用户行为。例如:上级有录入商品的权限,就能看到商品录入的操作,点击录入就可以进行商品的录入操作;反之没有该权限的下级就无法进行商品录入的操作。

    (红色的代表目录,蓝色的代表操作)

    2. 控制功能权限管理

    底层目录管理配置一般为开发人员一早就配置好,现在由用户进行分配使用这些功能权限。

    功能权限:以角色为基础,通过划分不同角色的不同功能权限,并将员工添加到对应的角色中,实现员工功能权限的区分和隔离,包括:

    • 对象级功能:比如功能的入口是否可见,如角色为“人事HR”,对“人员管理”的“查看列表”权限点取消,则此角色下员工不可见人员管理的功能入口。

    • 操作点权限:比如新建、编辑等业务操作;

    字段权限:在展示信息时加权限控制,保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如:为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。

    (字段权限细节)

    • 【读写】权限:员工将具备该字段的最大权限,【新建】【编辑】时可编辑,列表和详情页可见该字段。

    • 【只读】权限:员工在【新建】【编辑】时不可编辑,列表和详情页可见该字段。

    • 【不可见】权限:员工在【新建】【编辑】【列表】【详情】界面对该字段(或该字段值)不可见。

    功能权限对于前端界面的影响点:

    • 如果员工没有某对象“查看列表”的权限,则该对象的功能入口会被隐藏。

    • 如果员工没有某对象的操作点权限,则在对象页面上隐藏相应操作按钮。

    • 如果员工没有某对象的指定字段的可见权限,则在对象页面上隐藏相应字段。

    总结下:在权限管理中,需要遵循的一个重要的点:用户移动要匹配对应的操作。

    四、配置权限注意点

    产品设计支持后,配置权限需要注意以下几个要点:

    1. 确定是否支持前端配置

    如果角色和权限相对固定,则一般将角色与权限的关系可以写在后台,改动时需要后端变更且重新上线;这种情况适用于公司内部系统等只有一个使用主体的系统。

    如果需要自定义角色、或者每个角色在不同使用者的场景下有不同的权限,则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”;这种情况适用于有频繁变动的自定义角色权限,和有租户体系的系统。

    2. 以基本单元拆分,以业务逻辑配置

    一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方,在“人员管理”中,查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上,我们希望能尽量做到解耦和模块化。

    但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如,如果我们确定在系统的现有和未来业务中,仅分为普通成员有“人员管理”的查看权限,管理员有操作权限,则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。

    3. 页面权限优先于操作和数据权限

    必须配置了页面模块权限后,才能配置当前页面模块下具体的操作权限,以及页面模块的数据展示权限;

    4. 查看权限优先于增删改权限

    正常情况下,一定要先能查看某个模块或操作,其它的增删改操作才有意义。因此在设计时,应在获取查看权限前限制其它权限的配置;或者配置其它权限时默认赋予查看权限。

    5. 角色与权限的多种关系

    角色与权限的关系不仅是单纯“是/否关系”,还包括以某种限制进行操作,和以某种程度访问数据。例如在“人员管理”中:

    • 数据范围:用户拥有查看人员列表的权限,但仅能查看自己所在的团队;

    • 数据边界限制(上限等):添加人员时不能超过20个等。

    • 数据字段:HR能查看人员列表中包括职级、薪资等字段;其它角色仅能查看姓名邮箱等字段;

    6. 角色与权限的设计表达

    在传达一个系统的权限设计规则时,设计师常常习惯用主观最直接的方式表达想法,如用“当……时,就……”的句式来表达。但一个平台中涉及的权限规则是非常多的,当通篇以这样的形式描述时,表达对象将很难理解。

    正确的描述方式:更清晰的是基于开发的语言,和技术模型的结果进行表达:将各角色与权限单元绘制成网格,每个交叉点网格中描述该角色与权限的数据关系和限制。

    五、后台产品逻辑自查表

    后台产品逻辑遵循的就是八个字:“增(增加)”、“删(删除)”、“改(修改)”、“查(查询)”、“显(显示)”“算(算法)”、“传(传递)”和“异(异常)”。用一张表来整体看下自查表:

    后台权限不复杂,用户角色和权限一一对应匹配就好了。同样前端后台都不复杂,只要真实清楚的去了解业务就好了。

  • 相关阅读:
    常用正则表达式
    使 docker 容器可以正常 mount privileged
    yum源配置的三种方法
    LINUX 设置交换分区的大小
    查看php-fpm开启的进程数以及每个进程的内存限制
    深入php redis pconnect
    ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第六章:管理产品图片——多对多关系(上篇)
    ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第五章:排序、分页和路由
    ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第四章:更高级的数据管理
    ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之第三章:搜索、高级过滤和视图模型
  • 原文地址:https://www.cnblogs.com/zouhao/p/12193892.html
Copyright © 2011-2022 走看看