帖子
帖子
用户
博客
课程
12下一页
返回列表 发新帖
显示全部楼层
6
帖子
0
勋章
104
Y币

role roleMapping 权限说明

[复制链接]
发表于 2015-7-10 16:55:39
本帖最后由 ghostljj 于 2015-7-10 17:04 编辑

根据我的理解,希望能帮助到大家

role表 是权限列表。
roleMapping 关联权限(例如那个用户在那个权限里面,或者权限里面包含那个权限)

roleMapping的数据不能单独添加。必须在role表中的principals里面双击关联,

例如
1、在role表中添加一个name=管理员,点击principals进入roleMapping子表,principalType=USER,principalId=[会员id]

2、在role表中添加一个name=普通会员,点击principals进入roleMapping子表,principalType=USER,principalId=[会员id],
再点击普通会员的principals进入roleMapping子表,principalType=ROLE,principalId=[role表中管理员的id]

这样就建立了一个管理员和普通会员



首先解释几点:
权限总共是有四种:(就是设置表权限的右边那个)
第一种是所有用户都可以的everyone(所有用户都拥有该权限 )
第二种是只有用户自己才能有权限的owner(仅登录用户拥有该权限)
第三种是角色限制,可以嵌套角色,需要设置role表中的name而非id
第四种是用户限制,这个就没有可说的了。

owner设置中需要注意的一些地方,判断是否为owner的方法是,用户登录完后会在accessToken里边增加一条信息,里边有登录用户的userId。然后每次携带token进行访问的时候如果是owner权限的设置,就比对当前数据与id或者userId是否相同(user表的时候对比id,其他表对比的是userId),所以如果要使用owner权限需要新加一列userId字段(注意大小写,而且是string类型,不是pointer类型)。
注意:owner权限只能用在get、update、delete上。如果用在find下面,根本无法查询到表。所以不行。

例如_user 表,就是owner权限,可以参考看下。


二三四的关系是或的关系,这样就增加了权限设置的灵活性,例如信息只能自己或者自己的上级领导可以修改,就可以设置owner+role或user限制



谢谢 数据云咨询-北 提供的帮助。总结出来让那个好多人能了解。


1682
帖子
10
勋章
104
Y币
感谢分享
0
帖子
0
勋章
6
Y币
本帖最后由 anthonyhl 于 2015-7-30 13:32 编辑

补充说明,几个基本概念
1. 权限是用户访问资源的能力。在apicloud的设计中,class是资源,user是用户(身份)。
每个class的权限就是指一个那些user,可以访问这个资源。
2. 资源的访问分为多种操作,每个操作都有独立的权限控制,即Get/Post/Detele/Update分别指定那些用户。
3.指定用户的方式有三个大类,一是public, 即所有人;二是protected特定的人,登录用户owner或指定用户id,三是protected不特定的一组人,即按身份来划分。
4.owner类别有一点特别,每个指定这个权限的资源需要一个userId字段,这个字段指明了谁是owner.
对于User Class,这个字段就是id。
最复杂,灵活的是按身份划分的问题。

role class就是身份,roleMapping是一个属于关联,分成user和role两类。

user类的roleMapping很好理解,指一些user属于这个身份,即这些用户有身份相应的权限。例如,id=3xxxxxx的用户,属于role普通用户,那么role
class中普通用户这一行,principals字段对应的子表中,就会有一行principal_id=3xxxxxx的记录。这是一个多对多的关系

role类的roleMapping实际上应该是一个树(或者森林),例如经理role具备所有员工role的权限,反之不然。所以经理role对应的rolemapping表中,应
有一行principal_id=[员工role的id]。这应该是一个一对多的关系(高级权限role对应多个低权限的role)

注意这两类roleMapping的记录可以同时出现,也应该同时出现。

以我的设计经验来看,应该先考虑定义资源,确定其归属(是否适用于owner权限),或者属于一个身份。
身份系统要简单,够用即可,将来可以一个身份分解成多个,用于细分权限,但很难进行身份合并。
身份的设计最好映射现实的情况,从大向小的设计,如员工,HR部门员工,HR部门XX组员工。尽量不要树形,而是增加特定身份
在员工身份之外设计,资源管理者身份,经理就是资源管理者+员工,当然为了方便也可以设计一个上层身份叫经理。

最后,记得把所有顶层身份都加入一个叫超级用户的身份中,这是为最后急救。

0
帖子
0
勋章
6
Y币
本帖最后由 anthonyhl 于 2015-7-30 13:33 编辑

重复,删除。
89
帖子
0
勋章
1万+
Y币
顶一下,这个不错!
5
帖子
0
勋章
29
Y币
这么高深的文档,居然是用户发出来的。官方文档真是少的可怜。
8
帖子
0
勋章
578
Y币
顶到前面去!
33
帖子
0
勋章
417
Y币
本帖最后由 早起是病 于 2015-10-16 10:52 编辑

说的好像有一些错误。最起码在你两次的描述中把role说的矛盾了。开始你举例是普通会员中的rolemapping中写管理员的id,然后第二段中又又说是经理的rolemapping中写员工的id。这两种说法矛盾。应该是你第2次举例说错了。role通过principals列来关联rolemapping。利用了relation关系中单向关联的特点,设置role管理包含use。但是role管理包含role正好相反。是在低级role的rolemapping中添加高级role的id。
0
帖子
0
勋章
417
Y币
楼上早起早病的意见,楼主怎么没有回复?到底怎么回事?
1
帖子
0
勋章
25
Y币
同问同问
12下一页
您需要登录后才可以回帖 登录

本版积分规则