微信小程序新旧数据库权限对比

93 阅读 0 评论 62 点赞

我是靠谱客的博主知性抽屉，最近开发中收集的这篇文章主要介绍微信小程序新旧数据库权限对比，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

先说结论：新版规则如果妥善编辑安全规则与云函数，完全能够实现与旧版支持的所有安全规则。但是新版规则将权限划分得更细，并可以自己定义规则，所以灵活性、管理能力上比旧版要强。

旧版权限能力及行为

数据库的权限分为小程序端和管理端，管理端包括云函数端和控制台，我愿称之为后台。小程序端运行在小程序中，读写数据库受权限控制限制；管理端运行在云函数上，拥有所有读写数据库的权限。云控制台的权限同管理端，拥有所有权限。小程序端操作数据库应有严格的安全规则限制（需要调用微信小程序给出的接口，接口内封装了安全规则）。
云开发为云数据库做了小程序深度整合，在小程序中创建的每个数据库记录都会带有该记录创建者（即小程序用户）的信息，以 _openid 字段保存用户的 openid 在每个相应用户创建的记录中。因此，权限控制也相应围绕着一个用户是否应该拥有权限操作其他用户创建的数据展开。初期微信云开发数据库提供了四种基础权限配置，适用于简单的前端访问控制，只支持 4 种预设的规则（对集合中的每条数据记录）：

所有用户可读，仅创建者可写。比如文章。
仅创建者可读写。比如用私密相册。
所有用户可读，只有后台可以读写。如商品信息。
所有用户不可读写。如后台用的随机数等秘密信息。

但基础的设置给前端的访问权限控制是有一定局限性、同时会带来一些容易疑惑的、需要深入理解的系统默认行为，微信官方文档给出以下内容：

访问权限控制要求只能基于记录的 _openid 字段和用户的 openid，更新记录时，不允许修改 _openid
当权限为 “仅创建者可读写” 时，查询时会默认给查询条件加上一条 _openid 必须等于用户 openid
当权限为 “仅创建者可读写” 或 “所有用户可读，仅创建者可写” 时，更新前会默认先带上 _openid 必须等于用户 openid 的查询条件，再将查询到的结果进行更新，即使是用 doc.update 也是如此（因此我们会见到即使我们没有对应 _id 的记录的访问权限，但是更新操作不会失败，只会在返回的结果中说明 updated 更新的记录数量为 0）。
创建记录时，会自动给记录加上 _openid 字段，值等于用户 openid，并且不允许用户在创建记录时尝试设置 _openid
根据以上的描述，不难看出旧版的安全规则是完全基于openid的，所以对这条数据的管理增加了相当多的限制，如创建时默认生成、不允许用户更改等。

新版规则与能力

在官方给出的新版规则模板中，已经实现了旧版的四项能力，不过额外需要在云函数中插入_openid:{openid}的条件判断。如：

{
// 所有用户可读，仅创建者可写
"read": true,
"write": "doc._openid == auth.openid"
}
{
// 仅创建者可读写
"read": "doc._openid == auth.openid",
"write": "doc._openid == auth.openid"
}

新版规则对于想在云端对数据进行增删改查时，必须手动键入openid的判断条件，因为此时的openid将不再是必选的。而且旧版的安全规则是只区分了“读”和“写”，并没有进一步细分“写”的内容。在新版安全规则下，微信将“写”细分为 create、update、delete。所以可以构造更加复杂的安全规则，如：

{
// 自定义的对帖子的基本操作
"read": "auth != null", // 所有登录用户可读
"create": "auth != null", // 所有登录用户可以发帖
"update": "doc._openid == auth.openid", // 用户只能修改自己的帖子
"delete": "doc._openid == auth.openid" // 用户只能删除自己的帖子
}

上面的auth就是用户的登录信息，auth==null表示用户还没有登录，而auth.openid就表示用户的openid，doc.userID表示这条数据库所有者的id。
升级由于openid不再是显式传入的，如doc一类基于id的操作往往是规则禁止的，为了方便管理，微信官方建议换成where并显式添加openid的判断条件。带来的兼容性问题官方也给出了相应的文档说明：升级与兼容说明
综合来看，微信小程序新版的安全功能粒度会更加细一些，可以自己定义对数据的操作能力。所以总体而言，对应的灵活度上升了。

权限测试

新旧版的规则差异，其实说穿了就是一点：旧版规则相对死板，但是对应的接口比较完整，wx内会默认完成当前openid是否有权限的判断；新版规则相对灵活，为了减少束缚可以自己调整接口，默认是不会进行openid的匹配的。例如如果在云函数中不写_openid:‘{openid}’的话，就会变成所有人可读。
现在举一个云函数的例子如下：

// 云函数入口文件
const cloud = require('wx-server-sdk')
cloud.init({
env:'xixotest1-1scbh'
})
const db=cloud.database().collection("huangqiangBook2")
// 云函数入口函数
exports.main = async (event,context) => {
let { OPENID, APPID, UNIONID } = cloud.getWXContext()
return await db.where({
// _openid: OPENID,
// _id:"e6a3b07d5eeae2f2000a964b0dd3a761"
}).get()
}

云函数大致框架，修改部分就是where中注释掉的两行（上述代码块中13，14行）。
当权限规则设置是：

{
"read": "doc._openid == auth.openid",
"write": "doc._openid == auth.openid"
}

分别采用本地调用和云函数调用。由于本地调用中默认会进行openid的比较，当数据库中有若干条不满足访问条件的数据时，会发生“越权访问”的报错，从而导致一条数据也无法返回。当采用云函数调用时，如果加上对应openid的判断，由于云函数中访问数据时，如果出现越权访问的情况，是不会抛出异常的，取而代之的是返回结果为空。所以在云函数中访问时才可以比较适配兼容这种“新规则”。总体来看云函数具有更好的规则兼容性。