ACL 权限管理开发指南
ACL 是 Access Control List 的缩写,称为访问控制列表,包含了对一个对象或一条记录可进行何种操作的权限定义。
TDS 云端使用的 ACL 机制是将每个操作授权给特定的 User 用户或者 Role 角色,只允许这些用户或角色对一个对象执行这些操作。
例如如下 ACL 定义:
{
"*":{
"read":true,
"write":false
},
"role:admin":{
"read":true,
"write":true
},
"58113fbda0bb9f0061ddc869":{
"read":true,
"write":true
}
}
- 所有人可读,但不能写(
*
代表所有人)。 - 角色为 admin(包含子角色)的用户可读可 写。
- ID 为
58113fbda0bb9f0061ddc869
的用户可读可写。
我们使用内建数据表 _User
来维护 用户/账户系统,以及内建数据表 _Role
来维护角色。
角色既可以包含用户,也可以包含其他角色,也就是说角色有层次关系,将权限授予一个角色代表该角色所包含的其他角色也会得到相应的权限。
云端对客户端发过来的每一个请求都要进行用户身份鉴别和 ACL 访问授权的严格检查。因此,使用 ACL 可以灵活且最大程度地保护应用数据,提升访问安全。
默认 ACL
每个 Class 的初始默认 ACL 为所有人可读可写:
{
"*":{
"read":true,
"write":true
}
}
在创建 Class 对话框可以设置 Class 的默认 ACL:
你可以设置 read 和 write 权限开放给哪些用户,其中:
- 「所有用户」、「指定用户」可以参考数据安全指南的 Class 层面的访问权限一节的说明。
- 「数据创建者(Owner)」指创建数据的用户。也就是说,新增对象(create)时附带的
X-LC-Session
HTTP 头对应的用户。
除了分别设置 read 和 write 权限开放给哪些用户外,对话框中还提供了一些常用设定的快捷方式:
- 限制写入:数据创建者可读、可写,其他用户可读、不可写。
- 限制读取:数据创建者可读、可写,其他用户不可读、不可写。
- 限制所有:数据创建者可读、不可写,其他用户不可读、不可写。
- 无限制:所有人可读、可写。
对于已经存在的 Class,你可以更新默认 ACL 和访问权限。 进入**开发者中心 > 你的游戏 > 游戏服务 > 云服务 > 数据存储 > 结构化数据**,选择一个 Class,再点击权限标签页。 不过,修改默认 ACL 只作用于新增的对象,现存对象的 ACL 值保持不变。
除了设置默认 ACL 外,在控制台也可以设置单个对象的 ACL。
不过在控制台手工为每个对象设置 ACL 过于繁琐,并不现实。
所以通常我们在控制台设置默认 ACL,确保所有新创建的对象都有合适的初始 ACL 值。
为单个对象设置更复杂、更精细的 ACL,则通过代码设置其 ACL
字段。
例如,Post
Class 的默认 ACL 可能是这样的:
- read:所有用户
- write:数据创建者(Owner)
也就是说,所有用户都可以查看帖子,用户只能修改或者删除自己发的帖子。
这里数据创建者指创建对象的请求的 HTTP 头中携带的 session token 对应的用户,在我们的例子中是帖子的作者。