设计师在进行设计时,常常会抽象出对产品有诉求的多个角色,再依据角色的特性去梳理使用场景并设计。
当角色之间的使用场景不冲突,不需要隔离时,我们会综合考虑这些角色的使用场景来设计解决方案:比如网易云音乐同时为需要听歌和听电台的用户提供所有的功能;
当这些角色的使用场景完全不重叠、流程对立时,我们会设计完全独立的两套系统,如滴滴的司机端和乘客端;
但除了以上两种情况,在大多数B端产品中,基于流程公正性、信息安全性等因素考虑,各个角色的使用场景是部分通用,部分隔离的,这时候就需要引入“权限系统”了。
设计师有时会对角色权限系统有一丝畏难情绪。一方面因为角色权限系统的配置作为一个非常后台的管理功能,在竞品调研过程中很难通过上帝视角去解剖其中逻辑,自己琢磨又较难透彻;另一方面对于角色权限系统,做好了并不能代表设计能力有多优秀,但一旦没做好就会导致整个流程不通、产品崩溃。所以设计师常对权限系统望而却步。
以下就笔者的几次权限设计经历,提供一些所谓的经验套路,希望各位设计师从此微笑迎接权限需求。
✨
#
进行设计前,最好能够理解技术模型。在业界接受度较高的功能权限模型是RBAC(Role-Based Access Control)模型,其基本理念是将“角色”这个概念赋予用户,在系统中用户与权限之间通过角色进行关联,以这样的方法来实现灵活配置。以下就模型与设计相关的几点做一下简单介绍。
1. 基本的RBAC模型
如果没有角色的概念,系统中每加入一个用户,就需要为这个用户配置一遍权限,下图是wiki中直接为用户权限管理方式,可以看出管理成本巨大。
而引入“角色”概念后,如下图即是RBAC模型中最基本的模型:用户与角色可为多对一或多对多的关系,当一个用户的角色为多对多时,当前用户的权限是多个角色的并集。
此时只需要为角色赋予权限,能够大大减轻管理负担,同时将用户与权限解耦,提供更大的灵活性。
2. 引入用户组概念的RBAC模型
在大型平台的应用上,试想如果用户量上万,新增一个角色时,可能需要为大量用户都分配一遍新的角色,工程量仍然巨大,此时即可以引入用户组的概念:如果部分用户的使用场景是相对一致和基础的,我们可以把这些用户打包成一个组,基于这个组的对象进行角色和权限的赋予。
同理如果权限较多时也会存在一样的问题,处理方式是引入权限组的概念,将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的,所以实际应用中对权限组的使用较少。
下图所示为mac系统中运行添加用户组,并以用户组为单位配置权限;
需要注意的是即使有用户组或权限组的存在,也可以允许用户或权限与角色直接关联,这个可以视具体业务情况而定。
3. 角色继承的RBAC模型
在一个业务场景中,如果角色需区分:设计主管、设计组长、设计成员,并且管理方式为向下兼容时,则需使用角色继承的RBAC模型:上层角色继承下层角色的全部权限,且可额外赋予权限。
此时除了对角色进行定义,还需要管理角色间的关系,通过关系来体现角色的层级关系,从而达到继承权限的效果。角色的继承关系主要有两种:树形图和有向无环图:
继承关系常常来源于公司团队的组织结构,此时常将角色与组织结构进行关联达到继承角色模型的效果;如下图所示的赵同学,其角色是“三级团队负责人”,与其并列的小组中有多个“三级团队负责人”的角色,但依附于左侧的组织结构树,各级负责人仅有查看和操作自己下属子节点的权限。
4. 限制的RBAC模型
在一个产品或系统中,部分角色可能是需要隔离的、不允许被同时赋予一个人的。跟大家熟知的“不能既是‘运动员’又是‘裁判员’ ”一个道理。
因此,对于众多角色中的一组,只能是单选的关系,但多组角色之间可以共同存在。如下图中,一个用户可以既为设计师又为管理员,但在设计师角色组中仅能被赋予一个角色,在管理员角色组中也仅能被赋予一个角色。
此外,限制还有可能是数量上的,比如一个产品组中必须有且只有一个管理员,不允许删除或再分配管理员角色,仅允许将负责人角色变更。
限制的模型不仅仅对分配过程产生影响,有时即使拥有了多种角色,因为不同的角色对同一个功能的使用方式或数据会产生冲突,所以使用时也需要进行限制。如下图所示为同一时间仅允许以一个身份登录。
根据不同的业务需求,限制的形式很多。需要注意的是不能仅依赖后端限制,而是要在前端展示清晰的规则和恰当的限制,避免用户出错和沮丧。
✨
通过RBAC模型已经能够很好的搭建起用户、角色与权限之间的关系了。但具体是什么样的关系,以及“权限”这个抽象的概念具体如何规划?这些都需要分析清楚才能进一步设计出完善的权限系统。
首先需要知道,一般产品的权限由页面、操作和数据构成。页面与操作相互关联,必须拥有页面权限,才能分配该页面下对应的操作权限。数据可被增删改查。整体关系如下图所示:
因此,在设计之初我们就需要考虑到未来可能区分角色的地方,尽量解耦、模块化。对于技术来说,每一个页面模块、每一个操作都最好使用独立的接口。对于设计来说,需要保障所有角色因为权限而屏蔽掉部分操作和数据后,页面和流程仍能体验流畅。
保证初期设计支持后,配置权限时,还需要注意以下几点:
1. 确定是否支持前端配置
如果角色和权限相对固定,则一般将角色与权限的关系可以写在后台,改动时需要后端变更且重新上线;这种情况适用于公司内部系统等只有一个使用主体的系统。
如果需要自定义角色、或者每个角色在不同使用者的场景下有不同的权限,则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”;这种情况适用于有频繁变动的自定义角色权限,和有租户体系的系统。
2. 以基本单元拆分,以业务逻辑配置
一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方,在“人员管理”中,查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上,我们希望能尽量做到解耦和模块化。
但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如,如果我们确定在系统的现有和未来业务中,仅分为普通成员有“人员管理”的查看权限,管理员有操作权限,则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。
3. 页面权限优先于操作和数据权限
必须配置了页面模块权限后,才能配置当前页面模块下具体的操作权限,以及页面模块的数据展示权限;
正常情况下,一定要先能查看某个模块或操作,其它的增删改操作才有意义。因此在设计时,应在获取查看权限前限制其它权限的配置;或者配置其它权限时默认赋予查看权限。
角色与权限的关系不仅是单纯“是/否关系”,还包括以某种限制进行操作,和以某种程度访问数据。例如在“人员管理”中:
数据范围: 用户拥有查看人员列表的权限,但仅能查看自己所在的团队;
数据边界限制(上限等):添加人员时不能超过20个等。
数据字段: HR能查看人员列表中包括职级、薪资等字段;其它角色仅能查看姓名邮箱等字段;
在传达一个系统的权限设计规则时,设计师常常习惯用主观最直接的方式表达想法,如用“当……时,就……”的句式来表达。但一个平台中涉及的权限规则是非常多的,当通篇以这样的形式描述时,表达对象将很难理解。
正确的描述方式: 更清晰的是基于开发的语言,和技术模型的结果进行表达:将各角色与权限单元绘制成网格,每个交叉点网格中描述该角色与权限的数据关系和限制。如下图所示:
✨
1. 隐形的admin
在可自定义角色和权限的系统中,一般需要预留一个admin角色来进行系统的初始配置,用于添加首批的业务人员和配置基本的角色。
有的系统中允许存在上帝视角的admin角色,则其可以作为“超级管理员”显示在角色配置的列表中;有的系统中不允许这种角色存在,则可将这种角色设置为隐形的状态,仅赋予维护系统的工作人员。
2. 初始权限的赋予
对于允许用户自行加入的系统,需要设定一至多个默认的角色,有时可以是仅有最基础权限的“游客”角色。
初始权限还可以与用户既有的某些数据字段进行关联。如添加用户时获取到用户的岗位为“设计师”,则直接赋予“设计师”角色的权限。
3. 人员管理中对自己的处理
在人员管理中,管理员角色处理自己时需要额外注意:因为如果修改或删除了自己角色后,可能导致系统没有管理角色,从而无法添加其他成员和正常运行。设计时可添加判断,当自己为唯一管理角色时,禁止编辑和删除。
4. 无页面权限的提示
虽然可以通过页面权限限制直接隐藏当前用户没有权限的页面,但不能排除用户获取到权限外的url地址。当用户意外访问到没有权限的页面时务必提供“无权限”的提示,避免用户认为系统bug。
✨
总结一下,整个权限系统设计就是定义各个节点和节点间关系的过程。
用户
用户组
角色
角色组
权限(页面、操作、数据)
权限组(页面、操作、数据)
是/否关系
继承关系
限制关系(互斥、范围限制、边界限制、字段限制……)
……
梳理清楚所有逻辑后,通过灵活定义节点和组合各节点之间的关,便能够轻松完成角色权限设计的100种解法。
Mongodb批量操作,如批量删除,批量修改字段
http或https不带www的域名301跳转到带www的URL
gcc版本老旧,经常会碰到的问题:/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found。不要在网上找各种方法,直接升级gcc吧
error: ER_NOT_SUPPORTED_AUTH_MODE: Client does not support authentication protocol requested by serv
mongoose条件操作符
redis配置多个端口,redis启动多个实例
linux如何挂载新买的硬盘?
vim编辑nginx conf文件时,设置高亮/显示行号
vi/vim打开文件提示Found a swap file by the name
linux报错:C++ compiler too old, need g++ 4.9.4 or clang++ 3.4.2 (CXX=g++)
linux下如何安装nodejs
linux下安装 redis,以及相关使用
linux下通过yum安装mongodb
需要跨域的项目,很多时候每次都会发送OPTIONS请求,能不能优化呢?
mongodb多表关联查询
角色、权限、用户之间的关系,以及如何设计
这样形如 A.B.C 的字符串时能敏感地认出这是使用了 jwt。发了这两篇文章后,有不少读者在文末留言,表达了对 jwt 使用方式的一些疑惑,以及到底哪些场景适合使用 jwt。我并不是 jwt 方面的专家,和不少读者一样,起初研究时我也存在相同疑惑,甚至在逐渐接触后产生了更大的疑惑,经过这段时间项目中的使用和一些自己思考,把个人的总结整理成此文。
go语言实现token自动续期
RSA加密的玩法
捕获save报错,返回controller
win10下安装nginx,配置返向代理
ERROR 9076 nodejs.SequelizeConnectionError: Client does not support authentication protocol requested by server; consider upgrading MySQL client
RPM是RedHat Package Manager(RedHat软件包管理工具)类似Windows里面的“添加/删除程序
Ubuntu 16.04 发布时,一个引人注目的新特性便是 apt 命令的引入。其实早在 2014 年,apt 命令就已经发布了第一个稳定版,只是直到 2016 年的 Ubuntu 16.04 系统发布时才开始引人关注。随着 apt install package 命令的使用频率和普遍性逐步超过 apt-get install package,越来越多的其它 Linux 发行版也开始遵循 Ubuntu 的脚步,开始鼓励用户使用 apt 而不是 apt-get。
centos查看环境变量与设置环境变量在使用过程中很常见,本文整理了一些常用的与环境变量相关的命令,感兴趣的朋友可以参考下希望对你有所帮助
linux cenos下安装oh my zsh,oh my zsh 用于管理zsh配置,使shell界面更美观。 Zsh 是一款功能强大终端(shell)软件,既可以作为一个交互式终端,也可以作为一个脚本解释器。它在兼容 Bash 的同时 (默认不兼容,除非设置成 emulate sh) 还有提供了很多改进。
以腾讯云为例,配置nginx,实现https访问
nginx设置二级域名指向子目录
发现ip访问比nginx快多了,知道nginx出问题了~ 得给他优化优化。优化后由原来的2.7s打开,到600ms打开~nginx优化还是有用的
通过nginx开启gzip设置
通过Nginx反向代理,在一个云服务器上绑定多个域名,不同的域名访问不同的目录,端口
如何在Linux(CentOS 7)上安装Nginx,作为反向代理服务器。
nginx服务端实现CORS跨域配置
UUID,是Universally Unique Identifier的缩写,UUID出现的目的,是为了让分布式系统可以不借助中心节点,就可以生成UUID来标识一些唯一的信息;
命令从指定点开始将 File 参数指定的文件写到标准输出。如果没有指定文件,那么会使用标准输入。Number 变量指定将多少单元写到标准输出。Number 变量的值可以是正的或负的整数。如果值的前面有 +(加号),从文件开头指定的单元数开始将文件写到标准输出。如果值的前面有 -(减号),那么从文件末尾指定的单元数开始将文件写到标准输出。如果值前面没有 +(加号)或 -(减号),那么从文件末尾指定的单元号开始读取文件
今天想对一个问题进行分析和讨论,就是关于爬虫对网站页面爬取的问题,有些网站通过爬虫去采集其它的网站页面信息作为己用,大量的爬取行为会对web服务器有比较性能有影响,主要的表现就是会变得很慢。
将不带www的域名301重定向到带www的域名,利于SEO