uni-app uniCloud schema校验

uni-app uniCloud schema校验

操作步骤:

  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步

预期结果:

修改user_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": "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"
      }
    }
  }
}

更多关于uni-app uniCloud schema校验的实战教程也可以访问 https://www.itying.com/category-93-b0.html

7 回复

你是用admin测试的?你上面说的校验是是权限校验是吧?admin是拥有全部权限的,user_id改为和系统id等长的乱字符串时,检验无法通过——与期望一致这条确定是这个表现吗?

更多关于uni-app uniCloud schema校验的实战教程也可以访问 https://www.itying.com/category-93-b0.html


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的用户身份访问,居然能获取到这条数据

补充一下,上面1中说的admin意思是我用的uniCloud admin项目测试的,但是用的非admin账号

请问,有进展么?

回复 4***@qq.com: 一般来说确认是用户id类型的数据存储在库里的都应该是符合系统_id长度的,但是这个表现确实不应该,我排查下

回复 4***@qq.com: 此问题会在下个alpha版本发布时修复

回到顶部