【问题标题】:cloud firestore role based access example: can user create a comment?cloud firestore 基于角色的访问示例:用户可以创建评论吗?
【发布时间】:2021-05-21 21:30:31
【问题描述】:

在阅读基于云防火墙角色的访问示例https://firebase.google.com/docs/firestore/solutions/role-based-access#rules,第4步时,我发现用户是否可以创建评论并不清楚。

根据上面的链接,评论归用户所有,这里是数据模型:

/stories/{storyid}/comments/{commentid}
{
  user: "alice",
  content: "I think this is a great story!"
}

还有规则:

match /comments/{comment} {
  allow read: if isOneOfRoles(get(/databases/$(database)/documents/stories/$(story)),
                              ['owner', 'writer', 'commenter', 'reader']);
  // Owners, writers, and commenters can create comments. The
  // user id in the comment document must match the requesting
  // user's id.
  //
  // Note: we have to use get() here to retrieve the story
  // document so that we can check the user's role.
  allow create: if isOneOfRoles(get(/databases/$(database)/documents/stories/$(story)),
                                ['owner', 'writer', 'commenter'])
                && request.resource.data.user == request.auth.uid;
}

注意规则的最后一行,要创建评论,经过身份验证的用户 (request.auth.uid) 必须是评论所有者的用户。但是,在创建此评论之前,此用户属性如何存在?也许,在创建评论时,不需要规则“&& request.resource.data.user == request.auth.uid”的最后一段。但是在更新评论的时候,可以添加这条规则。

我错过了什么吗?顺便说一句,在将示例用于在线参考之前,他们是否真的测试了示例?也很遗憾,这些在线文档创建时没有时间戳。现在有人告诉我,两年前的东西可能已经过时了。

【问题讨论】:

    标签: database google-cloud-firestore firebase-security


    【解决方案1】:

    request.resource 变量包含该操作完成后将存在的文档(假设它是允许的)。所以request.resource.data.user 是操作尝试写入的user 字段的值,而不是当前存在的值(即resource.data.user,没有request.)。

    【讨论】:

    • 你说得有道理!!我仍然觉得这有点误导。因为网络上的描述说“验证评论的所有者与请求用户匹配,从而防止用户覆盖彼此的 cmets:”上面代码之间的 cmets 也说“//评论文档中的用户 id 必须匹配请求//用户的 ID。”所以这里的“评论文档中的用户 ID”来自 request.resource 并与 request.auth.uid 进行比较? request.auth.uid 如何提供不同的用户 ID 以供评论?谢谢!
    • 1) 每个文档页面都应该有一个链接可以留下反馈,所以我建议填写它。 2) 我可以尝试在文档中写入您的 UID,但我永远无法将您的 UID 放入 request.auth.uid(因为它由 Firebase 身份验证填充)。如果这一切都令人困惑,我建议您在操场上尝试一下 - 您可以重演您所询问的大多数场景。
    • 1) 是的,我看到底部有一个反馈按钮。但由于我没有看到任何以前的反馈,所以我犹豫了。在stackoverflow,它更透明,所以在这里我感觉更舒服。 2)我还是想不通,在创建评论时,request.auth.uid应该保存为评论文档中的用户id,即request.resource.data.user只能这样被定义/填充。如果在操场上尝试是指模拟器,谢谢,我稍后会尝试。
    • 当我有足够的声望点时,我肯定会点击upvote。已经单击复选标记。还发现这个 request.resource.data.authorId 在 youtube.com/watch?v=8Mzb9zmnbJs&t=980s 上得到了很好的解释,日期为 2020 年 8 月 4 日,最近。但老实说,我仍然觉得有些 uid (myId) 有可能为 myId 创建的东西提供不同的 id (theirId) 有点奇怪。对我来说,这似乎是一个等待被利用的错误。无论如何,我知道的很少,很乐意使用它是什么:)
    • 如果您找到了利用您认为存在的错误的方法,请在此处发布相关代码。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-04-08
    • 2022-09-27
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多