权限控制
用户配置系统菜单，操作权限（菜单和操作按钮有一套标码规范，名称、id等）-》用户配置用户角色的菜单、操作权限->后台生成权限树->用户登录业务系统，根据权限树控制菜单和操作->后台拦截器控制请求
作者：huiter
链接：https://www.zhihu.com/question/20313385/answer/118571022
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
链接：https://www.zhihu.com/question/20313385/answer/118571022
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
最近正好要重做权限系统的设计。
参考了RBAC（Role-Based Access Control，基于角色的访问控制）
不过觉得过于复杂，所以整理了一套简单的权限模型：
权限系统通常包括如下基本元素：
用户、角色、权限、资源、操作。
角色的本质是『权限的集合』，我简单分为两类：
身份角色：总经理、A项目负责人、B项目负责人、工程师、设计师
权限角色：A项目权限、B项目权限、若干文件权限
有的权限系统，一个用户只能有一个身份。
但现实中即使身份角色，一个人也可能有多重身份，所以会带来限制。
所以在简化模型中，一个用户可以对应多个角色。
权限，我简单分为两类：
批量权限，比如『访问项目列表权限』、『删除设备权限』、『组织架构管理』。
单一资源权限，比如『A文件的访问权』，『A文件的删除权』这类权限就是跟资源、操作相关。
批量权限，通常会有批量授权给一批用户。
单一资源权限，通常会授权给指定用户。
整理为简单的权限模型：
权限，分为『批量权限』、『单一资源权限』。
角色，为『批量权限』的集合。
用户，可以同时具有多个『角色』。
用户，可以同时具有多项『批量权限』。
用户，可以同时具有多项『单一资源权限』。
用户的权限集 ＝ 用户的『批量权限』 + 用户的『单一资源权限』+ 用户的所有『角色』的权限
另外用户创建的资源时，可以获得对应『单一资源权限』的权限。
权限管理系统的迭代过程：
比如，系统中有门店管理、文件管理、22个应用。
我们用模型 1，我们可以给一个用户分配门店管理，1、2号应用权限。
但随着用户量增多至 1000 时，系统中新增 23 号应用，北京的用户可以获得 23号应用的权限。
这时，一个一个修改用户的权限已经无法满足的需求了，所以可以引入模型 2，创建角色"北京"，并把用户进行关联。
这样我们可以直接修改"北京"角色的权限集，就完成了多用户的权限分配。
这里角色可以是用户组、权限组，本质上还是权限的集合。
进一步，我们有1000个门店，但是要分为10个大区，每个大区都有管理员，他们自己看到自己有权限的门店。这时，我们可以用模型 3，记录都有哪些用户具有该门店的访问权限。因为一个用户可管理的资源可能很多，所有访问权限可以存储在门店的结构中。这个场景中，直接使用了用户与权限的关联，避免了需要创建大量的角色。
再往后发展，可能会希望角色也可以关联单一资源权限、角色可继承。
但是这些可能会使得权限管理变得复杂，提升商户的操作门槛。
目前做过的项目，模式 3 都很少用到。
从商户的视角，他可以在权限管理中，管理子账号的批量权限。
在门店管理中，分配每个门店的访问权限。
这样时简单可接受的。
系统管理员，来管理角色及角色的分配，时机成熟可以将角色管理一部分下放给商户。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
参考了RBAC（Role-Based Access Control，基于角色的访问控制）
不过觉得过于复杂，所以整理了一套简单的权限模型：
权限系统通常包括如下基本元素：
用户、角色、权限、资源、操作。
角色的本质是『权限的集合』，我简单分为两类：
身份角色：总经理、A项目负责人、B项目负责人、工程师、设计师
权限角色：A项目权限、B项目权限、若干文件权限
有的权限系统，一个用户只能有一个身份。
但现实中即使身份角色，一个人也可能有多重身份，所以会带来限制。
所以在简化模型中，一个用户可以对应多个角色。
权限，我简单分为两类：
批量权限，比如『访问项目列表权限』、『删除设备权限』、『组织架构管理』。
单一资源权限，比如『A文件的访问权』，『A文件的删除权』这类权限就是跟资源、操作相关。
批量权限，通常会有批量授权给一批用户。
单一资源权限，通常会授权给指定用户。
整理为简单的权限模型：
权限，分为『批量权限』、『单一资源权限』。
角色，为『批量权限』的集合。
用户，可以同时具有多个『角色』。
用户，可以同时具有多项『批量权限』。
用户，可以同时具有多项『单一资源权限』。
用户的权限集 ＝ 用户的『批量权限』 + 用户的『单一资源权限』+ 用户的所有『角色』的权限
另外用户创建的资源时，可以获得对应『单一资源权限』的权限。
权限管理系统的迭代过程：
1. 用户 <- 批量权限
2. 用户 <- 角色 <- 批量权限
用户 <- 批量权限
3. 用户 <- 角色 <- 批量权限
用户 <- 批量权限
用户 -> 单一资源权限
<- 箭头指向表示关联关系的存储位置。
比如，系统中有门店管理、文件管理、22个应用。
我们用模型 1，我们可以给一个用户分配门店管理，1、2号应用权限。
但随着用户量增多至 1000 时，系统中新增 23 号应用，北京的用户可以获得 23号应用的权限。
这时，一个一个修改用户的权限已经无法满足的需求了，所以可以引入模型 2，创建角色"北京"，并把用户进行关联。
这样我们可以直接修改"北京"角色的权限集，就完成了多用户的权限分配。
这里角色可以是用户组、权限组，本质上还是权限的集合。
进一步，我们有1000个门店，但是要分为10个大区，每个大区都有管理员，他们自己看到自己有权限的门店。这时，我们可以用模型 3，记录都有哪些用户具有该门店的访问权限。因为一个用户可管理的资源可能很多，所有访问权限可以存储在门店的结构中。这个场景中，直接使用了用户与权限的关联，避免了需要创建大量的角色。
再往后发展，可能会希望角色也可以关联单一资源权限、角色可继承。
但是这些可能会使得权限管理变得复杂，提升商户的操作门槛。
目前做过的项目，模式 3 都很少用到。
从商户的视角，他可以在权限管理中，管理子账号的批量权限。
在门店管理中，分配每个门店的访问权限。
这样时简单可接受的。
系统管理员，来管理角色及角色的分配，时机成熟可以将角色管理一部分下放给商户。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
可以提供一个简化权限系统的设计例子。
