Firebase

Question

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

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

这似乎是一个普遍的要求，因为我基本上在我们需要的每个 table 中都看到了它。例如我们有 users，我们有 projects，我们在一个项目中有 tasks，等等。对于这些数据类型中的每一种，总有一些字段是 user-editable 和那些不是。

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

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:

顺便说一下，暗示应该使用我上面的第一个选项，但我想更笼统地构建这个问题，看看是否确实有任何最佳实践。

Answer 1

有一整套涵盖最佳实践的指南，包括有关 data structures and security related to auth 的主题，其中包括现场演示。

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

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

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

{
  "rules": {
     "users": {
        "$uid": {
           // allow write access to email but not paid status
           "email": ".write": "auth.uid === $uid"
        }
     }
  }
}

Firebase - 在安全和不安全字段之间拆分表

Firebase - splitting tables between secure and insecure fields

firebase-security

firebase-authentication