在Firebase实时数据库规则中，如何为具有特定子值的用户授予写访问权限？

如何解决在Firebase实时数据库规则中，如何为具有特定子值的用户授予写访问权限？

,"people" : {
  ".read": "auth != null","$uid":  {
  },"e2" : {     
    ".read": "auth.uid != null",".write": "$uid == auth.uid"  
  },"l1" : {     
    ".read": "auth.uid != null",".write": "auth.uid != null"  
  }

所以e2是电子邮件的@。例如@gmail或@aol或@yahoo。对于l1的孩子，我想制定一条写规则：如果auth.uid！= null && e2与要写l1的人的e2的值相同，则写。我能得到的最远的是这样的：

"data.parent().child(people).hasChildren(['auth.uid','l1'])"    

JSON

"people": {
    "02PdiNpmW3MMyJt3qPuRyTpHLaw2": {
        "e2": "aol.com","l1": 4,"X": {
            "e2": "aol.com","l1": 0,"P": {
                "e2": "gmail.com",

基本上l1 = like，因此用户以向计数加1的形式写另一个用户的l1。

应该成功的操作：

用户X希望喜欢使用uid 02PdiNpmW3MMyJt3qPuRyTpHLaw2的用户。用户X的e2子级为@ aol.com。这与他想要喜欢的用户的e2子代相同。用户x也是授权用户，因此满足写给他想要的用户l1的2个要求。

不成功的操作：

用户P希望使用uid 02PdiNpmW3MMyJt3qPuRyTpHLaw2的用户。用户P的e2子级为@ gmail.com。这与他要喜欢的用户的e2子代不同。因此，用户P不满足写给他想要的用户的l1的要求

解决方法

这是一个真正涉及的场景，因此我将逐步介绍它。您很有可能需要进行更改以使这些规则适用于您的完整用例，因此，我希望每个步骤都能使您自己进行调整。

---

第一步是对数据结构进行模糊处理。相反，我将使用此结构来开始：

{
  "people" : {
    "user1" : {
      "domain" : "aol.com","likeCount" : 2,"likers" : {
        "user2" : {
          "comain" : "aol.com"
        },"user3" : {
          "domain" : "aol.com"
        }
      }
    }
  }
}

因此user1有两个喜欢的人，分别来自同一域的user2和user3。

我高度建议您在数据库中总体上使用这样有意义的名称，但是绝对要在您对此发布的问题中使用。如果人们不容易理解您的数据模型，那么他们提供帮助的机会就会迅速下降。

---

在上述数据模型中，我们可以确保只有来自同一域的用户才能通过以下方式喜欢该用户：

  "people": {
    "$uid": {
      "likers": {
        "$likerid": {
          ".write": "data.parent().parent().child('domain').val() == newData.child('domain').val()"
        }
      }
    }
  }

使用这些规则，我尝试了对people/user1/likers/user4的两次写操作。第一个操作成功：

{
  "domain": "aol.com"
}

第二项操作失败：

{
  "domain": "gmail.com"
}

---

我们可能还应该确保用户只能写自己的喜欢，而不能写其他用户。我们可以这样：

  "people": {
    "$uid": {
      "likers": {
        "$likerid": {
          ".write": "$likerid == auth.uid && 
            data.parent().parent().child('domain').val() == newData.child('domain').val()"
        }
      }
    }
  }

---

接下来，我们将添加一条规则，该规则允许用户只有在以前不喜欢某人的情况下才喜欢某人。我们将在people/$uid上执行此操作，因为我们需要尽快查看likers下和likesCount下的数据。

第一步的规则是：

  "people": {
    "$uid": {
      ".write": "
        !data.child('likers').child(auth.uid).exists() && newData.child('likers').child(auth.uid).exists()
      ","likers": {
        "$likerid": {
          ".write": "$likerid == auth.uid && 
            data.parent().parent().child('domain').val() == newData.child('domain').val()"
        }
      }
    }

因此，如果我们要添加尚不存在的赞，这些规则将使我们能够写给用户。您可能需要在此处进行其他检查，以允许更新其他子节点，但是在此，我们将使事情尽可能简单（因为它已经相当复杂）。

---

最后，您要确保写入操作还必须增加likeCount，它应该是这样的：

  "people": {
    "$uid": {
      ".write": "
        !data.child('likers').child(auth.uid).exists() && newData.child('likers').child(auth.uid).exists()
        && newData.child('likeCount').val() == data.child('likeCount').val() + 1
      ","likers": {
        "$likerid": {
          ".write": "$likerid == auth.uid && 
            data.parent().parent().child('domain').val() == newData.child('domain').val()"
        }
      }
    }

因此，新行现在检查likeCount处的新数据是否比以前的值高一个。

---

我已经在自己的测试数据库中完成了上述每个步骤，并在操场上对阳性和阴性病例进行了测试。因此，尽管可能存在一些问题，但每个步骤的基本方法都行得通。

正如所说的，这很复杂，很可能需要进行重大更改，才能对所有用例完全起作用。