如何设计网站权限系统?

请说一下设计思想和设计的技术,我会自己去钻研。 当然如果有例子(可以引用),那就再感谢不过啦 ^_^
关注者
427
被浏览
27416

12 个回答

后台产品狗,之前踩过权限控制系统的大坑。

做完项目整体复盘,发现坑爹的不是难设计,而是对现有权限控制情况的了解程度低。

如果在平台设计之初就考虑到权限控制的问题,是好事。

越早进行系统的考虑,成本越低,效果也越好。

最好的当然是之前有成熟的系统可以接入复用。

如果没有的话,那就得尝试自己理解这一套东西,并深入了解现有情况再进行设计了。


谈到权限控制的设计,需要先理清楚定义和原理。

所以我们需要看到权限控制中,控制的本质,也就是说控制的是什么?

其实是:用户与可以进行的行为的关联关系

这句话中有3个关键词:用户、行为、关联关系。

衍生出如下几个问题

关于用户

  • 用户是怎么分类的(用户角色)
  • 用户和用户之间是否有关系?如果有,是什么关系?关系是什么结构的?
    • 如公司组织架构那种层级分明的树形结构

关于行为

  • 怎么将行为分类(一般来说按照行为目的区分、按照行为业务类别区分、按照行为与系统的交互类型区分)
    • 例如,按照行为与系统的交互类型区分
      • 数据权限:指的是用户有权操作的那部分数据(读、写)
      • 功能权限:对使用人群在功能修改使用等方面权利的限制
  • 行为之间是否有层级和依赖关系,是怎么样的依赖关系

关于关联关系

  • 是一对一还是一对多,如果有父子层级之分,是继承关系还是独立存在。

这是概念层的问题,具体到工作的设计当中,用于梳理需求会有一些帮助,主要还是用于梳理基础概念。

一句话概括就是:权限系统维护的是人和可进行行为的关联关系。

那么系统的每个用户可以看做是一堆可以进行的行为的集合。

这句话有点不好理解的话,你就按照用户画像那么理解,在权限系统里,每个用户身上打满了一堆可以进行行为的标签。



那么权限控制系统的原理呢? 其实很简单,就是: 用户在访问时,通过了解用户具有的可以进行的行为的集合,决定用户可以看到什么菜单,以及在什么菜单下能使用什么功能,并且具备什么样操作数据的能力。

了解完概念,那么在动手之前,是了解清楚需求及目前的解决方案。 比如: 现在都有什么类型的用户? 每个类型的用户在使用功能上有什么区分? 现在一级菜单和二级菜单都有哪些? 每个页面上面通用的和需要控制的功能都有什么? 哪些数据的读写需要根据用户身份做区分? PS:大部分没有权限控制之前,很多权限控制是写死在代码里了,需要梳理清楚,避免踩坑。

好了,其实回答完以上问题,应该能了解自己或公司对权限系统的基本需求了,按照我的习惯,就可以着手开始写use case了。

具体的情况,具体分析,最大的难点在于对现有情况的了解,了解清楚现有情况,其实设计难度不大。

更多阅读:RBAC权限管理

感谢 @万丞敬 的回答。
最近正好要重做权限系统的设计。
参考了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 都很少用到。

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

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

===============
可以提供一个简化权限系统的设计例子。
LeanCloud 文档
为什么?