【问题标题】:Firebase Security Prevent Save Data From Other UserFirebase 安全性阻止从其他用户保存数据
【发布时间】:2016-12-18 12:16:44
【问题描述】:

我得到了这样的 firebase 数据库结构:

database
   - chat
        -user1
             -user2
                -chat1
                   -message : a
        -user2
             -user1
                -chat1
                   -message : a
             -user3
                -chat1
                   -message : a
         -user3
             -user2
                -chat1
                   -message : a

问题是,如何防止用户(如果是 user1)从 user3user2 写入聊天消息。

示例:

我是 user1 使用 javascript 命令

firebase.database().ref("chat/user2/user3/chat2").set({
     message: "HAHA"
});

上面的命令说我作为 user1user3user2 写新的聊天,并带有消息 “HAHA”。我想用 firebase 规则来防止这种情况。有人可以帮我写规则和我应该使用的登录方法吗?

谢谢。

【问题讨论】:

    标签: firebase firebase-realtime-database firebase-authentication firebase-security


    【解决方案1】:

    看起来你的结构如下:

    chats
        $recipientUid
            $senderUid
                $chatMessageId
    

    确保只有发件人可以写信是:

    {
      "rules": {
        "chat": {
          "$recipientUid": {
            "$senderUid": {
              ".write": "auth.uid == $senderUid"
            }
          }
        }
      }
    }
    

    将特定用户之间的消息存储在类似聊天室的结构中更为常见。见Best way to manage Chat channels in Firebase

    【讨论】:

    • 感谢先生的回答,但现在的问题是 uid 不是从 firebase 用户生成的 uid。它是来自用户(用户名)的字符串。我可以将 senderUid 与用户指定的字符串进行比较吗?我想我现在无法重组数据库.. 超过 500 人使用它,我无法删除所有这些聊天..
    • 为了保护特定用户对数据的访问,您必须在安全规则中设置某种方式将节点与特定用户关联。这只能通过auth 变量来完成。最常用的属性是auth.uid。除非您正在铸造自定义令牌,否则您的 username 不会成为 auth 变量的一部分,因此无法基于此来保护访问。
    • auth.token.name 怎么样?先生,我可以使用它吗?
    • 除非您正在铸造自定义令牌(我非常怀疑),否则auth 变量中可用的信息有限。您使用的用户名是什么?它从何而来?如果它是用户在您的应用程序中输入的内容,它不会神奇地出现在 auth 变量中。但是您可能能够以某种方式将auth.uid 映射到用户名。请注意,所有这些信息在您的原始问题中都非常有用。使用edit 链接添加它。
    【解决方案2】:

    您是否尝试过来自 firebase documentation 的数据结构? 因为在你的情况下,我认为这样做是不可能的,因此你需要扁平化你的数据库结构。即使您可以使用通配符,但仍然很难做到,因为在一个客户端中只有一个 uid,因此您不能在不知道前端的 uid 的情况下真正在其他用户的节点中编写“聊天消息”。

    我的建议,尝试通过思考“聊天参与者如何访问他们自己的聊天数据库?”来修改结构。您可以简单地使用每个用户可以在其他人可以阅读的“聊天室”中写入他们自己的节点的规则。 CMIIW

    问候,

    R。 M.

    【讨论】:

      猜你喜欢
      • 2016-05-23
      • 2018-12-08
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-11-17
      • 1970-01-01
      • 2016-03-23
      • 2018-09-13
      相关资源
      最近更新 更多