首页 » 划重点 » 后台权限管理,看这篇就够了!(内附5本启示录第二版实体书福利)

后台权限管理,看这篇就够了!(内附5本启示录第二版实体书福利)

2019-09-10 1255736f015b8ad0 划重点
不管是2C产品经理还是2B产品经理,都要将权限管理法则烂熟于心。只有熟悉权限管理法则,才能更好地理解自己产品的架构,做到每次产品迭代都心里有数。

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

当角色之间的使用场景不冲突,不需要隔离时,我们会综合考虑这些角色的使用场景来设计解决方案。比如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. 角色与权限的设计表达

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

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

五、后台产品逻辑自查表

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


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

上一篇文章是一个视频,很多小伙伴都看了好几遍,是关于产品经理工作流程的全解释。可以看看:

(产品经理工作流十二步)

提前祝大家中秋节快乐……为此John这边准备了5本启示录的书籍抽奖。




(启示录第二版)

推荐理由:


为什么亚马逊、谷歌、脸书的产品全世界数以亿计的用户都喜欢?你可能不知道,它们的产品开发模式与大多数公司很不一样。在本书中,科技产品管理领域的思想领袖马丁•卡根给读者带来了生动的大师课:如果要创造出用户喜爱的产品,如何搭建结构?如何安排人员?如何授权?如何高效组织?也就是说,如何发现用户喜爱的产品,并且把它交付出来。还有最重要的:如何在你的企业实现这一切。

第二版时隔十年全面更新,马丁•卡根在书中呈现了大量最新、最成功的科技公司的案例,以及他十年来更深刻的领悟和洞见。无论你所在的组织是希望创造爆款的初创型企业,还是希望迅速扩大规模的成长型企业,抑或是希望自我更新再上层楼的成熟型企业,本书都能帮助你把产品打造、用户参与、持续创新等提高到一个新水平。


抽书链接:(长按识别小程序即可参与啦)


准备重启下知识星球。因为有很多小伙伴单独问问题:消息太多,一直都没有时间回复——其实意念已经回复了。肯定一个小门槛……(由于没有留言功能)。所以调研下:



点个
“在看”
吧。写文不易。

历史文章:(其他的查看历史文章吧)
一文详解产品经理工作流程

产品经理快速积累经验的八条铁律

产品经理做好产品的几个关键点。(文末有行业地图下载)

腾讯八节产品课——教你产品从0到1的思考

关于产品的19条随笔,建议看一看

产品经理跳槽面试大揭秘

一文理清产品规划究竟怎么做(内附案例剖析)

一文详聊产品经理必须要具备的技术思维

2019年度6月份app排行榜,另附Q1行业分析报告PDF下载

向经典致敬,张小龙关于产品的68句话,你值得收藏


说点什么
头像
沙发还空着,发表你的看法吧ヾ(≧▽≦*)o
Loading...
上一篇 下一篇
已跳转到上次阅读的位置,从头阅读?