多组织多用户Firestore权限设计：求无需get()的优雅方案

针对你的电商SaaS权限需求，以下是几种无需在规则中调用get()的低成本方案，适配多组织、多角色、细粒度权限的场景：

方案1：压缩权限到Custom Claims（推荐） #

利用Firebase Auth的Custom Claims存储用户在各组织的权限/角色，规则直接从request.auth.token读取，完全避免额外读取操作。

具体实现： #

• 用角色映射细粒度权限：先定义角色与权限的对应关系（后台统一配置），例如：
  • admin：拥有products.read、products.write、orders.read、orders.write所有权限
  • editor：拥有products.read、products.write、orders.read
  • viewer：仅拥有products.read、orders.read
• 在Custom Claims中存储用户的组织-角色映射，格式如下：

  {
    "org_roles": {
      "org_12345": "admin",
      "org_67890": "viewer"
    }
  }
  

• Firestore规则中预定义角色权限映射，直接校验：

  function hasOrgPermission(orgId, requiredPerm) {
    // 先校验用户是否属于该组织
    if (!request.auth.token.org_roles || !request.auth.token.org_roles[orgId]) {
      return false;
    }
    // 预定义角色对应的细粒度权限
    const rolePerms = {
      "admin": ["products.read", "products.write", "orders.read", "orders.write"],
      "editor": ["products.read", "products.write", "orders.read"],
      "viewer": ["products.read", "orders.read"]
    };
    const userRole = request.auth.token.org_roles[orgId];
    return rolePerms[userRole] && rolePerms[userRole].includes(requiredPerm);
  }
  
  // 示例：校验商品读取权限
  match /organisations/{orgId}/products/{productId} {
    allow read: if hasOrgPermission(orgId, "products.read");
    allow write: if hasOrgPermission(orgId, "products.write");
  }
  

优势： #

• 规则无需get()，零额外读取成本
• 角色复用减少Claims存储空间（Custom Claims上限1000字节，足够大部分用户关联5-10个组织的角色存储）
• 权限更新通过Admin SDK批量操作，安全可控

局限性： #

• 若用户关联超10个以上组织，可能超出Claims空间限制，需结合其他方案补充

方案2：细粒度权限编码压缩（适合权限灵活度高的场景） #

如果需要完全自定义的细粒度权限（而非固定角色），可以将权限编码为短字符串存储到Claims中：

• 例如把products.read缩写为pr、products.write缩写为pw，每个组织的权限用逗号分隔：

  {
    "org_perms": {
      "org_12345": "pr,pw,or,ow",
      "org_67890": "pr,or"
    }
  }
  

• 规则中解码并校验：

  function hasOrgPermission(orgId, requiredPerm) {
    const permMap = {
      "pr": "products.read",
      "pw": "products.write",
      "or": "orders.read",
      "ow": "orders.write"
    };
    if (!request.auth.token.org_perms || !request.auth.token.org_perms[orgId]) {
      return false;
    }
    const userPerms = request.auth.token.org_perms[orgId].split(",");
    return userPerms.includes(Object.keys(permMap).find(key => permMap[key] === requiredPerm));
  }
  

优势： #

• 保留细粒度权限的灵活性
• 同样无需get()，成本低

局限性： #

• 权限编码需要前后端统一维护，增加少量维护成本
• 权限过多时仍可能占用较多Claims空间

补充说明：权限更新流程 #

无论哪种方案，Custom Claims的更新都需要通过Firebase Admin SDK实现（客户端无法直接修改），例如后端接口接收管理员的权限变更请求后，调用Admin SDK更新用户Claims：

// Node.js Admin SDK示例
admin.auth().setCustomUserClaims(uid, {
  org_roles: {
    "org_12345": "editor",
    "org_67890": "viewer"
  }
});

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