【user-center】Q&A

🎉完结撒花（不正经总结）

​ ”麻雀虽小、五脏俱全”，从整体上来说可能项目涉及的功能并不复杂，总结下来就是小码农们又爱又恨的CRUD，但在这个过程中比起功能的实现，更重要的是关注具体企业级流程开发以及开发过程中的一些应用技巧和解决方案。

​ 从需求分析->环境构建->应用开发->上线部署->运维等方面了解各个环境的工作内容和技巧，不仅可以帮助新手掌握企业级项目开发的技巧、夯实项目基础，于我这个小油条而言也可在此基础上查缺补漏，跳脱固有的开发思维模式，吸取别人的项目开发经验，也可在此基础上分享自己的看法和所得。

​ 一个统一的用户中心对于企业级应用开发而言是一个非常重要的存在，在原有模式的折磨下，我也曾经历过n个单体应用的开发，每个系统用户、权限管控都是”随心所欲”的概念，甚至并没有一套相对统一的机制去做处理，以至于后期的维护和迭代异常痛苦。于是抽空去了解项目，慢慢地去完善用户、权限管控机制，逐渐形成一套相对统一的用户体系作为项目开发迭代的基础， 让子系统在这个基础上扩展自身属性

1.权限管理的场景

​ 权限管理可以简化理解为“用户可以干什么”，用于控制用户访问功能或者资源，在后台管理系统设计中应用广泛。权限管理的模型有许多，例如自主访问控制(DAC，Discretionary Access Control)、强制访问控制 (MAC，Mandatory Access Control)、基于角色访问控制 (RBAC，Role-based Access Control) 和基于属性访问控制 (ABAC，Attribute-based Access Control)

​ 其中RBAC（基于角色的权限控制）应用较为广泛，其在用户和资源之间引入角色、权限概念。其核心要素为用户、角色、权限，而RBAC主要是基于用户拥有什么角色、角色映射何种权限、权限对应什么功能或者资源这几个问题提供的一种解决方案。

​ 传统的最简单的最理想的情况，一个用户对应一个身份访问相应的功能权限，这种模式下根据用户身份进行校验放行即可（对应到代码中最简单的一种实现形式就是if...else...概念）。

​ 但针对比较复杂的公司内部结构或者业务场景，则往往需要对每个用户的身份和职责进行相应的管控，当用户达到一定的量时除却一些特殊的业务场景，不可能每次变动时都手动去调整用户的角色、权限（重复工作量和维护量）。

​ 引入“组别”概念，将拥有共同职责的用户划分为一个组，将权限绑定到对应组中。基于这种场景，每个用户可以拥有一个或多个不同的角色，而每个角色绑定相应的权限列表，当用户岗位或者部门发生变动时，则依据其职责调整其绑定的角色即可

​ 不管是前端还是后台，都有相应的RBAC通用框架，最主要的是结合实际的业务场景拆分面向的对象维护，划分相应的内容即可，其核心原理主要是校验用户身份->查验用户关联角色绑定的权限列表->确认是否放行资源，了解这一基本概念，在引用或者设计一些RBAC相关框架的时候便可结合应用去掌握相应的原理实现。

​ 后台：拦截接口->校验登录身份->查验角色、权限列表->确认资源是否放行->响应数据

​ 前台：拦截路由->校验登录身份->查验后端返回或者已缓存的角色、权限列表信息->动态加载菜单或者按钮、动态校验UI操作

​ 从某种程度上来说，前后端是一个互补概念，前端在UI操作上限制常规的用户行为，用户只能访问提供的操作范围；而后端则是进一步在接口层限制一些异常的请求操作，从而避免一些非法操作造成数据冗余或者打破常规业务逻辑