用户权限设计（用户权限设计的需求来源是什么）
xmtyy5 天前14 次查看
本文作者结合实际经验，讲述了如何基于RBAC模型设计后台用户和权限。一起来看看吧~
一、项目背景 1.1 需求来源
前段时间，笔者所在的公司接到了多位客户对后台权限和角色的要求。讨论发现现有的产品后端架构不能很好的满足用户的需求，所以为了满足这些客户的需求角色设计比例理论，为未来可能的业务扩展打下基础，我们决定在后端进行迭代——现有产品的最终用户系统。
1.2 拆解需求
通过过滤需求，我们发现用户需求主要有两类：
二、理论基础
说到后台用户管理系统，不可避免的概念就是权限，任何账户都会有自己的用例。但在大多数情况下，我们会对一些账户的用例施加一些限制。如果直接在账户中加入这样的限制，会出现两个问题：
因此，角色的诞生即将浮出水面。我们通过对权限集进行抽象来创建一个角色，并对角色进行修改，从而达到控制拥有该角色的账户的权限修改的目的。
权限可以分为两类：数据权限和功能权限：
2.1 RBAC-0 模型
2.1.1 简要说明
RBAC-0模型的特点是用户和角色是多对多的关系，同一个用户具有多个角色的属性。我们通过组织的概念构建组织结构，从而实现角色数据权限的分配。这样，单个用户账户所拥有的所有权限角色设计比例理论，都是其所在组织权限的积累。
2.1.2 示例
在RBAC-0模型中，用户A负责组织X的业务，用户B负责组织Y的财务工作。正常情况下，A和B自然不能查看对方的数据，但如果有一天， B由于业务需要需要协助处理X组织的财务，那么我们可以将X组织的“财务”角色添加到B用户中来实现。种需求。业务结束后，也可以通过暂停/删除操作来管理B在X组织下的权限。
2.2 RBAC-1 模型
基于RBAC-0模型，根据角色继承的概念，子角色可以继承父角色的权限，但子角色的权限必须小于父角色的权限。
2.3 RBAC-2 模型
与RBAC-0系统相比，RBAC-2系统在用户与角色之间、角色与角色之间增加了一些规则。
2.4 RBAC-3 模型
RBAC-3 模型游戏运营，也称为统一模型，基于 RBAC-0，包含 RBAC-1 和 RBAC-2 模型的所有特征。
3. 设计流程 3.1 新账户属性
添加账户是用户系统最基本的功能。添加账户时需要获取账户的哪些参数，决定了整个用户系统的数据维度。
这里不得不提的是USER_ID、登录账号、昵称的概念。
USER_ID：对应账号在系统中的唯一标识，可能不会显示给用户，比如微信的open_id和union_id，一般是系统在添加账号时生成的，不能修改；
登录帐号：部分系统登录帐号与USER_ID不一致。同一个 USER_ID 可能对应多个登录帐户。比如微信可以通过微信ID、手机号、邮箱等方式登录。这里不同的登录方式对应这个登录账号。，一般由用户在添加账号时输入，不可修改；
昵称：昵称可以由用户自由编辑，用户输入，允许修改。
3.2 如何处理功能权限
功能权限是通过修改角色的权限树来实现的。在权限树中，我们可以列出页面权限、菜单权限和按钮权限，通过过滤对应的权限来完成对角色功能权限的控制。
需要注意的一个问题是权限控制的最小粒度。如果要实现对每个权限的控制，就相当于封装了每个权限对应的功能。大页面和菜单权限是必须的，但是哪些按钮权限可以封装在一起（比如“启用”和“暂停”一般成对出现）音乐音效，这些都需要产品自己考虑。
3.3 如何处理数据权利
数据权限其实是角色权限的一个重要属性，但是由于数据范围过于灵活，如果给角色添加“数据权限”选项卡，如果账户下的数据量很大，用户编辑数据的操作权限会很麻烦。因此，目前主流的后台设计都会使用“组织架构”来对应数据权限。
在系统中，我们使用【添加组织】的方式来处理数据权限。
3.4 老用户的兼容性
在重构用户系统时，老用户的账号兼容性是产品必须考虑的一部分。兼容性问题也是从功能和数据两个维度验证新系统是否对老用户产生影响。
4.总结
文章内容主要是本次迭代中的实际使用场景。以他山之石可以攻玉为思想，参考现有资料，结合我们自身系统的实际情况，对用户系统的设计进行了总结。如有不足，请多多交流，共同进步。
