Firestore同一账号下多档案的认证与管理方案咨询

一、Firestore规则中验证选中档案的方法 #

首先推荐采用清晰的集合结构：创建独立的profiles集合，每个文档代表一个档案，核心字段包含ownerUid（关联家长用户的UID）、name（档案名称）及其他业务字段。

1. 前端传递档案ID，规则验证归属 #

前端在发起请求时，通过路径参数或查询参数携带当前选中的profileId，规则中直接验证该档案属于当前认证用户：

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // 验证单个档案的读写权限
    match /profiles/{profileId} {
      allow read, write: if request.auth != null && resource.data.ownerUid == request.auth.uid;
    }

    // 查询用户名下所有档案的权限
    match /profiles/{profileId} {
      allow list: if request.auth != null && request.query.where('ownerUid', '==', request.auth.uid);
    }

    // 验证档案关联子集合（如孩子的记录）的访问权限
    match /profiles/{profileId}/child_records/{recordId} {
      allow read, write: if request.auth != null && 
        get(/databases/$(database)/documents/profiles/$(profileId)).data.ownerUid == request.auth.uid;
    }
  }
}

前端请求示例（JavaScript）：

// 从本地存储/状态管理中读取当前选中的档案ID
const selectedProfileId = localStorage.getItem('selectedProfileId');

// 查询该档案下的孩子记录
const recordsRef = db.collection(`profiles/${selectedProfileId}/child_records`);
recordsRef.get().then(snapshot => {
  // 处理返回数据
});

2. 用自定义Claims绑定活跃档案（进阶方案） #

若需要更严谨的身份绑定，可在用户切换档案时，通过云函数更新Firebase Auth的自定义Claims，将activeProfileId写入用户的ID Token：

云函数示例（Node.js）：

exports.setActiveProfile = functions.https.onCall(async (data, context) => {
  if (!context.auth) {
    throw new functions.https.HttpsError('unauthenticated', '用户未登录');
  }
  const { profileId } = data;
  // 先验证档案归属
  const profileDoc = await db.collection('profiles').doc(profileId).get();
  if (!profileDoc.exists || profileDoc.data().ownerUid !== context.auth.uid) {
    throw new functions.https.HttpsError('permission-denied', '无权限访问该档案');
  }
  // 更新自定义Claims
  await admin.auth().setCustomUserClaims(context.auth.uid, { activeProfileId: profileId });
  return { success: true };
});

对应的Firestore规则：

match /profiles/{profileId}/child_records/{recordId} {
  allow read, write: if request.auth != null && 
    request.auth.token.activeProfileId == profileId &&
    get(/databases/$(database)/documents/profiles/$(profileId)).data.ownerUid == request.auth.uid;
}

此方案避免前端篡改档案ID，但需要云函数支持，且切换档案后需用户刷新ID Token。

二、更简便的单用户多档案管理方式 #

1. 嵌套档案数组到用户文档 #

若档案结构简单（无复杂子集合），可直接在users/{uid}文档中添加profiles数组字段，存储所有档案信息：

// 用户文档示例结构
{
  "uid": "parent-123",
  "email": "parent@example.com",
  "profiles": [
    {
      "id": "p1",
      "name": "爸爸",
      "type": "adult"
    },
    {
      "id": "p2",
      "name": "小明",
      "type": "child"
    }
  ]
}

对应的Firestore规则：

match /users/{uid} {
  allow read, write: if request.auth != null && request.auth.uid == uid;
}

这种方式无需额外集合，读写效率更高，适合档案数据量小、无复杂关联的场景，前端只需本地维护当前选中的档案ID即可。

2. 轻量存储：利用用户元数据 #

若仅需存储少量档案ID，可将ID列表存入用户的displayName或自定义元数据中，但仅适合简单场景，不推荐存储复杂结构。

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