Q: 数据库明明有值,云函数查询结果却为空
A: 集合权限规则可能未修改:云开发 -> 数据库 -> 数据权限 -> 自定义规则
开发者工具 1.02.1911252 起支持配置
安全规则是一个让开发者可以灵活地自定义前端数据库读写权限的能力,通过配置安全规则,开发者可以精细化的控制集合中所有记录的读、写权限,自动拒绝不符合安全规则的前端数据库请求,保障数据安全。使用安全规则,你将获得以下能力:
_openid
字段和用户 openid
openid
同时随着安全规则的开放,前端批量更新(where.update
、where.remove
)也随之开放(基础库 2.9.4
起),开发者在进行批量更新时应搭配安全规则使用以保障数据安全。
安全规则要求前端发起的查询条件必须是安全规则的子集,否则拒绝访问。比如定义一个读写访问规则是 auth.openid == doc._openid
,则表示访问时的查询条件(doc
)的 openid
必须等于当前用户的 openid
(由系统赋值的不可篡改的 auth.openid
给出),如果查询条件没有包含这项,则表示尝试越权访问 _openid
字段不等于自身的记录,会被后台拒绝访问。
除了安全规则外,云开发数据库提供了四种基础权限配置,适用于简单的前端访问控制,只支持 4 种预设的规则(对集合中的每条数据记录):
但基础的设置给前端的访问权限控制是有一定局限性、同时会带来一些容易疑惑的、需要深入理解的系统默认行为:
_openid
字段和用户的 openid
,控制粒度较粗、相对不灵活_openid
必须等于用户 openid
_openid
必须等于用户 openid
的查询条件,再将查询到的结果进行更新,即使是用 doc.update
也是如此(因此我们会见到即使我们没有对应 _id
的记录的访问权限,但是更新操作不会失败,只会在返回的结果中说明 updated
更新的记录数量为 0)。_openid
字段,值等于用户 openid
,并且不允许用户在创建记录时尝试设置 _openid
_openid
因此,我们建议开发者使用新推出的数据库安全规则取代基础权限配置,可以让数据库访问的行为更加明确,同时取消需要深入理解的系统默认行为,让数据库权限控制更加简单明确。
新的安全规则与旧的四种基础权限配置的对应关系如下,我们在此先给出样例,下方再给出具体的安全规则使用指南:
新自定义安全规则与旧权限配置的对应关系
所有用户可读,仅创建者可写
{ "read": true, "write": "doc._openid == auth.openid" }
仅创建者可读写
{ "read": "doc._openid == auth.openid", "write": "doc._openid == auth.openid" }
所有用户可读
{ "read": true, "write": false }
所有用户不可读写
{ "read": false, "write": false }
我们可以在控制台对各个集合分别配置安全规则,入口在集合权限配置页,在基础的四种权限配置外还提供了 “自定义规则” 的选项。
每个集合都有独立的安全规则配置,配置的格式为 json
,比如如下一个在某集合上的安全规则配置:
{ "read": "true", "write": "auth.openid === doc._openid" }
这配置其实就对应着已有的 "所有用户可读,仅创建者可写" 这一权限配置。配置的 key
表示操作类型,value
是一个表达式,表示需要满足什么条件才允许相应的操作类型。当表达式解析为 true
时即代表相应类型的操作符合安全规则。
支持配置的操作类型如下:
操作类型 | 说明 | 默认值 |
---|---|---|
read | 读 | false |
write | 写,可以细分为 create、update、delete | false |
create | 新建 | 无 |
update | 更新 | 无 |
delete | 删除 | 无 |
规则表达式是类 js 的表达式,支持部分表达式,内置全局变量、全局函数。
变量 | 类型 | 说明 |
---|---|---|
auth |
object | 用户登录信息,auth.openid 是用户 openid |
doc |
object | 记录内容,用于匹配记录内容/查询条件 |
now |
number | 当前时间的时间戳 |