Firebase实时数据库规则问题：群组用户读取UserData权限配置

• 搭建多群组系统，支持一个群组包含多个用户、单个用户加入多个群组
• 用户拥有分级权限：读取其他成员数据、写入其他成员数据、修改成员权限
• 仅当群组成员的Groups/$group_id/Members/uid/canReadOthersData = true时，该成员可读取同群组其他成员的数据
• 用户数据固定存储在UserData路径，且该路径不可修改

当前规则代码中，UserData的.read规则无法通过root.child('Groups').child($group_id).child('Members').hasChild(auth.uid)判断用户是否属于某群组，原因如下：

• 在UserData的规则上下文里，无法获取$group_id变量
• Firebase规则不支持从UserData反向遍历查询用户所属的所有群组

是否需要调整数据结构，比如新增存储用户所属群组的路径？

{
  "rules": {

    "Groups": {
      "$group_id": {

        ".read": "data.child('Members').child(auth.uid).exists()",
        ".write": "data.child(auth.uid).child('canChangeRegistry').val() == true",
        "Members": {
          ".read": "data.child(auth.uid).exists()",
          ".write": "data.child(auth.uid).child('canChangeRegistry').val() == true",
          "$uid": {
            ".read": "data.child(auth.uid).exists()",
            ".write": "auth.uid === $uid || data.child('canChangeRegistry').val() == true"
          }
        }
      }
    },

    "UserData": {
      "$uid": {
        ".read": "auth.uid === $uid || root.child('Groups').child($group_id).child('Members').hasChild(auth.uid)",
        ".write": "auth.uid === $uid "
      }
    },

  }
}

没错，你必须调整数据结构，新增一个UserGroups节点来存储每个用户所属的群组信息——这是Firebase规则里实现这类反向权限校验的标准做法，因为Firebase规则不支持从Groups节点反向遍历查询用户所属群组。

调整后的数据结构 #

新增UserGroups节点作为用户与群组的关联索引，示例结构如下：

{
  "Groups": {
    "group_001": {
      "Members": {
        "user_001": { "canReadOthersData": true, "canChangeRegistry": false },
        "user_002": { "canReadOthersData": false, "canChangeRegistry": true }
      }
    }
  },
  "UserData": {
    "user_001": { "username": "张三" },
    "user_002": { "username": "李四" }
  },
  "UserGroups": {
    "user_001": {
      "group_001": true
    },
    "user_002": {
      "group_001": true
    }
  }
}

优化后的规则代码 #

{
  "rules": {
    "Groups": {
      "$group_id": {
        ".read": "root.child('UserGroups').child(auth.uid).child($group_id).exists()",
        ".write": "root.child('Groups').child($group_id).child('Members').child(auth.uid).child('canChangeRegistry').val() === true",
        "Members": {
          ".read": "root.child('UserGroups').child(auth.uid).child($group_id).exists()",
          ".write": "root.child('Groups').child($group_id).child('Members').child(auth.uid).child('canChangeRegistry').val() === true",
          "$uid": {
            ".read": "root.child('UserGroups').child(auth.uid).child($group_id).exists()",
            ".write": "auth.uid === $uid || root.child('Groups').child($group_id).child('Members').child(auth.uid).child('canChangeRegistry').val() === true"
          }
        }
      }
    },
    "UserData": {
      "$uid": {
        ".read": "auth.uid === $uid || (root.child('UserGroups').child(auth.uid).exists() && root.child('Groups').child(root.child('UserGroups').child(auth.uid).keys()).child('Members').child(auth.uid).child('canReadOthersData').val() === true)",
        ".write": "auth.uid === $uid"
      }
    },
    "UserGroups": {
      "$uid": {
        ".read": "auth.uid === $uid",
        ".write": "root.child('Groups').child(newData.key()).child('Members').child($uid).exists()"
      }
    }
  }
}

核心要点 #

• UserGroups的必要性：它相当于用户和群组之间的"索引"，让规则能直接快速查到当前用户所属的所有群组，解决了原规则中UserData上下文无法获取$group_id的问题。
• 权限逻辑修正：在UserData的.read规则里，先通过UserGroups确认用户属于某个群组，再校验该用户在对应群组里是否有canReadOthersData权限，完全匹配你设定的权限要求。
• 数据一致性保障：UserGroups的写入规则限制只有当用户确实被加入某个群组时，才能在该节点添加记录，避免出现用户不在群组但UserGroups里有记录的不一致情况。

内容的提问来源于stack exchange，提问作者4bottiglie