1.新建uniCloud admin项目，运行后登陆页创建一个admin用户
2.新建photos和projects两个表，然后到云数据库添加一条photos数据
{
"project_id": "60d158594cb09000011328d5",
"store_type": 1,
"store_key": "",
"user_id": "60d17be89dad850001cfaaa91"
}
3.修改上面photo数据的user_id，改成admin的用户id
4.新建一个页面，onLoad直接访问photos表数据
db.collection('photos').get()
5.更改user_id，在末尾多加一个字符串或减少一个字符串，重复第4步
4***@qq.com
- 发布：2021-06-23 21:30
- 更新：2021-06-24 18:15
- 阅读：839
产品分类： uniCloud/App
操作步骤：
预期结果：
修改user_id后，只要user_id和当前登陆用户的id不至于，就应该报权限错误
修改user_id后，只要user_id和当前登陆用户的id不至于，就应该报权限错误
实际结果：
当修改后的user_id长度和系统生成的id不一致时，权限校验没有起作用，全都会通过
当修改后的user_id长度和系统生成的id不一致时，权限校验没有起作用，全都会通过
bug描述：
read权限写成doc.user_id == auth.uid后，数据库里给这个表添加一条记录，
user_id设置为"1"、"12"这些和系统生成的id长度不一样的字符串，检验直接通过——与期望不一致
user_id改为和系统id等长的乱字符串时，检验无法通过——与期望一致
user_id改为当前用户id时，校验通过——与期望一致
user_id改为当前用户id后面再加几个字符时（长度大于系统生成的id），检验通过——与期望不一致
总结：当user_id和系统id长度不一致时，权限校验失效
麻烦看看是不是bug
下面是表结构
photos表
{
"bsonType": "object",
"required": [],
"permission": {
//"read": "get(`database.projects.${doc.project_id}`).user_id == auth.uid", // 这个也有问题，报错Cannot read property 'findSet' of undefined
"read": "doc.user_id == auth.uid",
"create": false,
"update": false,
"delete": false
},
"properties": {
"_id": {
"description": "ID，系统自动生成"
},
"user_id": {
"bsonType": "string",
"description": "商家（用户）id，参考uni-id-users表",
"foreignKey": "uni-id-users._id"
},
"project_id": {
"bsonType": "string",
"description": "所属项目id，参考`project`表",
"foreignKey": "projects._id"
},
"store_type": {
"bsonType": "int",
"description": "存储类型：0 未指定、1 uniCloud阿里云存储、2 uniCloud腾讯云存储"
},
"store_key": {
"bsonType": "string",
"description": "存储键值：存储类型为uniCloud阿里云或腾讯云时为云存储的ID"
}
}project表
{
"bsonType": "object",
"required": ["user_id", "name", "type"],
"permission": {
"read": "doc.user_id == auth.uid || 'admin' in auth.role",
"create": true,
"update": "doc.user_id == auth.uid",
"delete": "doc.user_id == auth.uid"
},
"properties": {
"_id": {
"description": "ID，系统自动生成"
},
"user_id": {
"bsonType": "string",
"description": "所属用户id，参考`user`表",
"foreignKey": "uni-id-users._id",
"forceDefaultValue": {
"$env": "uid"
}
},
"name": {
"bsonType": "string",
"description": "项目名称"
},
"type": {
"bsonType": "int",
"description": "类型：0 未指定、1 标准选片项目"
},
"status": {
"bsonType": "int",
"description": "状态：0 未发布、1 已发布、2 已完成",
"defaultValue": 0
},
"create_date": {
"bsonType": "timestamp",
"description": "创建时间",
"forceDefaultValue": {
"$env": "now"
}
}
}
}
4***@qq.com (作者)
1.我用的admin测试的
2.是权限校验，不过我用的非admin账号测试的
3.“user_id改为和系统id等长的乱字符串时，检验无法通过——与期望一致”意思是
假如我当前用户非admin且用户id为60d05feff183a00001f140ac
我请求的数据的user_id和系统生成的id长度一致，但是属于另一个用户，如
{
"name": "测试项目",
"user_id": "60d17be89dad850001cfaaa9"
}
这时候，权限系统工作正常，会返回“权限检测不通过”
但是，我贴子提的bug是，如果我把这条数据的user_id长度减少或增加，权限校验就直接通过了，比如数据改成
{
"name": "测试项目",
"user_id": "60d17"
}
或
{
"name": "测试项目",
"user_id": "60d17be89dad850001cfaaa900000000000"
}
这时候，以id为60d05feff183a00001f140ac的用户身份访问，居然能获取到这条数据
2021-06-26 00:42
4***@qq.com (作者)
补充一下，上面1中说的admin意思是我用的uniCloud admin项目测试的，但是用的非admin账号
2021-06-26 00:44
4***@qq.com (作者)
请问，有进展么？
2021-07-13 10:20
DCloud_uniCloud_WYQ
回复 4***@qq.com: 一般来说确认是用户id类型的数据存储在库里的都应该是符合系统_id长度的，但是这个表现确实不应该，我排查下
2021-07-13 12:01
DCloud_uniCloud_WYQ
回复 4***@qq.com: 此问题会在下个alpha版本发布时修复
2021-07-16 18:01