01 注册、登录模块
-
拉取第三方验证登录:
登录无需账户,但需要在第三方或账户管理处有识别账户的统一验证标识比如微软提供的邮箱后缀验证服务,首次登录时需要在系统后台中找到该用户,并给予用户可访问或其他权限,此时数据库中应存储用户标识信息与权限便于新增权限和记录用户操作记录。
-
注册登录:
用户首次注册登录时需填写必要信息,此时需要根据业务需求从而判断需要邮箱、手机号等第三方绑定账户。
一般情况下是可以通过手机号、微信号、QQ号等直接注册的。




02 用户管理(角色、账户和权限)模块

1. 角色管理
-
角色需要满足继承关系以此表明角色的上下级关系,此部分可以参考决策树根叶子节点来区分角色的父子关系。
-
角色需要满足存在着约束关系,以此来表明角色之间的不同点对应角色下设的权限和业务的不同。
-
先决条件角色:此情况考虑的是系统庞大时,用户在新增一个较高影响范围的角色和权限是否需要满足该角色下的子角色;
-
互斥角色:一个用户只能分配互斥角色组的一种,例如市场专员 、运营人员 、系统管理可以设置为互斥组,一个用户只能归属为其中一组;设置互斥组是处于对系统和业务安全性的考量,比如一个用户的角色是系统管理员的角色若赋予运营角色的权限在误点击的情况下就有可能会影响线上业务。但具体的互斥角色和对应的权限设置需要根据业务的实际情况设定。运行时互斥:一个用户可以拥有多个角色,但在实际业务操作运行中不可同时激活这两个角色以此达成动态职责分离。
-
角色列表页更便于系统管理员进行角色和用户的对应核验,对角色能进行增删改查基础功能外,也可以根据业务实际情况考虑是否新增自定义角色功能等,以此考虑系统的拓展性。
-
列表页 = 展示页 + 一些必要操作的入口;在列表页中可以将主要的信息展示出来比如角色ID、角色名称、权限、创建时间以及操作等;当基本权限和操作权限较多时可以仅展示一部分,剩余部分可以采用【光标移动到此字段时进行全部展示or在操作字段下多加一个查看操作进行详情页的形式】

-
“新增角色”和“编辑角色”都是给角色赋予相应的定义,但编辑角色需要考虑目前角色的使用情况,在已有的系统使用中是否已经存在并运行,当修改时是否会影响线上系统。赋予新增角色的权限是站在长期价值上考虑系统的可拓展性,在不断迭代的业务中新增业务模块和权限时无需接入新的开发,但同时更需要在一开始就做好相关的定义与新增的规则,所以在最初搭建时期不建议提供新增角色的功能。
-
当角色的权限较少时可以采用【下拉框】的形式来选择,当权限较多时可以采用【权限罗列】的形式。

2. 权限管理
-
RBAC定义:当一个操作,同时满足a与b时,允许操作:a.规定角色可以对哪些资源进行哪些操作 ;b.规定主体拥有哪些角色
-
RBAC的思想,来源于现实世界的企业结构。
-
在做权限梳理之前与业务和开发同学达成一致,确定哪些权限是同类型的、可同组聚合,而哪些业务或功能的权限是必须分开设定的。
-
【权限性质】部分是根据业务情况实际设置的需要规定好角色与【查看】、【操作】等权限的设置,在逻辑整体上需满足角色于权限的对应,从而实现不同角色对应的业务页面查看、编辑、删除等功能的不同操作,甚至同个页面的某些元素的查看、编辑、删除等功能根据角色与权限的对应关系可单独设定。
-
权限设定也可以考虑父子关系

3. 账户管理
-
列表页 = 展示页+一些必要操作的入口,列表页的主要作用是可以让用户清晰的查询到必要信息,比如用户ID、用户名、部门、角色、账号状态、注册时间以及操作(操作中首先应该具备“编辑”、“删除”基础的操作功能);
-
另一方面,某些账户可能存在冻结的情况(此情景状态在用户管理账户层级较少但某些业务场景中较为常见),基于此种情况需要新增增加“冻结”和“启用”的功能。
-
除此之外,便于后续的数据分析和操作记录可以前端做一些简单的数据埋点,比如最近登录时间、登录次数等。



