权限的问题

Question

在权限设计总role和group必须都用吗
只用role 或者 group 行不行?

Answer 1

你还可以再用个team呢。说白了，就是应用程序无法写死哪些用户有权使用自己，所以找出个中间概念来代替用户身份。随便你用什么名字，只要是这个功能就行了。

Answer 2

除了什么role、group、team，你还可以用department之类的，比如“只有老板的狗或者同类才能用他的专用厕所”这里的授权信息“老板的狗或者同类”就是一种授权，这就是一种角色。

Answer 3

我的理解是group 是用户的集合, role是操作的集合
可以用 user->group->role->操作 的方式得到一个用户的所有权限
我就觉得group->role 有点多余

Answer 4

“操作的集合”？这有些牵强。role是个非常宽广的概念，比group、department都作用广泛。比如可以代表我上面说的授权信息。所以role通常就够了。

Answer 5

role不是特定的什么“操作的集合”。他就是代表用户的。对于文件夹，它的“删除”操作允许匹配“系统管理员”，这里是操作匹配了一个role。role本身可不是什么操作。

Answer 6

那从user到操作 是怎样的一个关系? 对group和role是怎么使用的?能不能举例说明一下?

Answer 7

像这样 role就可以了 为什么还要弄一个group 甚至弄department出来呢?

Answer 8

已经说过了！应用程序是先有程序操作代码，然后运行时才去判断权限，所以它不可能预先写死用户列表。所以它需要在程序中写死的是：判断（随机变化的）用户是否具有某个授权信息（身份信息），也就是判断用户是否具有某个role信息。仅此而已。我上面也举了一例。负责处理“打开老板的厕所大门”的程序要验证当前用户是否具有“老板的狗及其同类”这个身份，如果有就让可以打开大门了。

Answer 9

有各种各样的原因。有的是为了抄袭别人的时髦文章，有的是为了实用。比如授权时有时候需要借用用户企业组织架构（某个部门、某个职位的人），有时候需要借用用户已经有的项目（某个小组的成员）等等。但是如果不从广泛的role入手，而是只能支持用户组织架构或者项目组，那么显然这个权限设计就不通用。

Answer 10

当然可以不用了，你可以设计四张表，分别存放用户信息（如用户名称+群组ID），群组信息，操作信息，群组操作关联信息（如群组ID+操作ID），用户跟群组绑定，群组跟操作信息绑定

Answer 11

那我可不可以这么理解 group  department的引入主要是配合企业的组织结构