1

在安全数据字段（不信任用户更新自己）和不安全数据之间构建 Firebase 表/对象是否有任何最佳实践，他们可以自己设置？

例如，用户应该可以在他们自己的users对象中自由更改他们的姓名或偏好，但他们不应该可以自由更改设置，例如他们是否是付费用户、他们的电子邮件是否已确认等。或者给用户一个特定的例如，user.name应该由用户直接编辑，而user.email只能通过我们自己的 API 进行更改，然后更新 Firebase 的记录。

这似乎必须是一个常见的要求，因为我基本上在我们需要的每个表中都看到了它。例如，我们有users，我们有projects，我们tasks在一个项目中，等等。对于这些数据类型中的每一种，总有一些字段是用户可编辑的，而有些则不是。

那么哪种方法是最佳实践呢？这里有两种可能性：

secure_data:
  users:
    user1:
      email:
    user2:
  projects:
  tasks:
insecure_data:
  users:
    user1:
      name:
    user2:
  projects:
  tasks:

或者：

users:
  user1:
    secure:
      email:
    insecure:
      name:
projects:
   project1:
     secure:
     insecure:
tasks:

顺便说一句，这个答案意味着应该使用我上面的第一个选项，但我想更一般地构建这个问题，看看是否确实有任何最佳实践。

4

1 回答 1

4

有一个涵盖最佳实践的完整指南，包括与 auth 相关的数据结构和安全性主题，其中包括现场演示。

由于之前链接的问题已经涵盖了读取安全数据的用例，我还假设您没有问同样的问题，并且您只对写入限制感兴趣。如果您想要阅读限制，那么这个问题是重复的；除非该路径中的所有数据都是可读的，否则您将无法在路径上进行迭代或查询。

写限制非常简单；仅授予对相关字段的写入权限。

例如，如果用户应该能够写电子邮件但不能写付费状态：

{
  "rules": {
     "users": {
        "$uid": {
           // allow write access to email but not paid status
           "email": ".write": "auth.uid === $uid"
        }
     }
  }
}
于 2015-10-27T18:34:47.730 回答