权限控制

用户配置系统菜单，操做权限（菜单和操做按钮有一套标码规范，名称、id等）-》用户配置用户角色的菜单、操做权限->后台生成权限树->用户登陆业务系统，根据权限树控制菜单和操做->后台拦截器控制请求

 

做者：huiter
连接：https://www.zhihu.com/question/20313385/answer/118571022
来源：知乎
著做权归做者全部，转载请联系做者得到受权。

最近正好要重作权限系统的设计。
参考了RBAC（Role-Based Access Control，基于角色的访问控制）
不过以为过于复杂，因此整理了一套简单的权限模型：

权限系统一般包括以下基本元素：
用户、角色、 权限、 资源、操做 。


角色的本质是『权限的集合』， 我简单分为两类：
身份角色：总经理、A项目负责人、B项目负责人、工程师、设计师
权限角色：A项目权限、B项目权限、若干文件权限

有的权限系统，一个用户只能有一个身份。
但现实中即便身份角色，一我的也可能有多重身份，因此会带来限制。
因此在简化模型中，一个用户能够对应多个角色。

权限，我简单分为两类：
批量权限，好比『访问项目列表权限』、『删除设备权限』、『组织架构管理』。
单一资源权限，好比『A文件的访问权』，『A文件的删除权』这类权限就是跟 资源、操做相关 。

批量权限，一般会有批量受权给一批用户。
单一资源权限，一般会受权给指定用户。


整理为简单的权限模型：
权限，分为『批量权限』、『单一资源权限』。
角色，为『批量权限』的集合。
用户，能够同时具备多个『角色』。
用户，能够同时具备多项『批量权限』。
用户，能够同时具备多项『单一资源权限』。

用户的权限集 ＝ 用户的『批量权限』 + 用户的『单一资源权限』+ 用户的全部『角色』的权限 
另外用户建立的资源时，能够得到对应『单一资源权限』的权限。

权限管理系统的迭代过程：

1. 用户 <- 批量权限

2. 用户 <- 角色 <- 批量权限
   用户 <- 批量权限

3. 用户 <- 角色 <- 批量权限
   用户 <- 批量权限
   用户 -> 单一资源权限

<- 箭头指向表示关联关系的存储位置。

好比，系统中有门店管理、文件管理、22个应用。

咱们用模型 1，咱们能够给一个用户分配门店管理，一、2号应用权限。
但随着用户量增多至 1000 时，系统中新增 23 号应用，北京的用户能够得到 23号应用的权限。
这时，一个一个修改用户的权限已经没法知足的需求了，因此能够引入模型 2，建立角色"北京"，并把用户进行关联。

这样咱们能够直接修改"北京"角色的权限集，就完成了多用户的权限分配。
这里角色能够是用户组、权限组，本质上仍是权限的集合。

进一步，咱们有1000个门店，可是要分为10个大区，每一个大区都有管理员，他们本身看到本身有权限的门店。这时，咱们能够用模型 3，记录都有哪些用户具备该门店的访问权限。由于一个用户可管理的资源可能不少，全部访问权限能够存储在门店的结构中。这个场景中，直接使用了用户与权限的关联，避免了须要建立大量的角色。

再日后发展，可能会但愿角色也能够关联单一资源权限、角色可继承。
可是这些可能会使得权限管理变得复杂，提高商户的操做门槛。
目前作过的项目，模式 3 都不多用到。

从商户的视角，他能够在权限管理中，管理子帐号的批量权限。
在门店管理中，分配每一个门店的访问权限。
这样时简单可接受的。

系统管理员，来管理角色及角色的分配，时机成熟能够将角色管理一部分下放给商户。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

能够提供一个简化权限系统的设计例子。