Firestore文档协作者添加方案：已知邮箱未知UID的角色权限实现

这问题我之前在做内部文档权限系统时碰到过——核心矛盾就是底层依赖UID做权限控制，但发起分享的用户只有目标邮箱，甚至不确定对方是否注册。下面是一套能满足你所有约束的落地方案：

核心思路 #

在应用层封装邮箱→UID的映射逻辑，把用户输入的邮箱转换成底层RBAC需要的UID，同时处理目标用户未注册的情况，全程不破坏「故事非公开、仅创建者和被分享者可读」的权限规则，也不改动底层基于UID的权限体系。

具体实现步骤 #

1. 应用层新增邮箱匹配与UID查询流程 #

• 当Alice输入Bob的邮箱发起分享时，后台先查用户数据库：
  • 如果找到Bob的UID（已注册）：直接调用底层RBAC接口，给该UID添加对应故事的读取权限。
  • 如果没找到UID（未注册）：生成一个临时UID，绑定该邮箱创建预注册记录，同时给这个临时UID添加故事的读取权限。

2. 未注册用户的权限激活逻辑 #

• 给Bob的邮箱发送专属邀请邮件，包含带校验参数的激活链接。
• 当Bob首次通过链接访问应用时，系统自动关联他的邮箱和之前生成的临时UID，完成正式注册，同时保留已赋予的故事读取权限。
• 如果Bob一直不激活，临时UID对应的权限不会泄露——因为只有持有该邮箱的用户能通过链接验证激活，其他用户无法获取权限。

3. 权限安全强化 #

• 所有分享操作必须先校验发起者的身份：只有故事创建者的UID能发起分享请求，杜绝越权。
• 底层RBAC的权限列表只存储UID，不暴露邮箱信息，保证和原有文档规则的兼容性。

示例伪代码 #

def share_story(story_id, creator_uid, target_email):
    # 第一步：校验创建者权限
    if not verify_story_creator(story_id, creator_uid):
        raise PermissionError("只有故事创建者才能发起分享")
    
    # 第二步：通过邮箱查找/生成UID
    target_uid = fetch_uid_by_email(target_email)
    if not target_uid:
        # 生成临时UID并创建预注册记录
        target_uid = generate_secure_temp_uid()
        create_pre_reg_user(target_uid, target_email, expires_after_days=30)
    
    # 第三步：调用底层RBAC接口添加读取权限
    rbac_add_permission(resource=story_id, subject=target_uid, action="read")

关键注意事项 #

• 临时UID的安全性：要用足够复杂的随机字符串（比如UUID v4）生成，避免被猜测；同时给预注册记录设置过期时间（比如30天），过期自动清理冗余数据。
• 邮箱唯一性：数据库要强制邮箱字段唯一，避免同一个邮箱对应多个UID的情况，保证映射关系准确。
• 分享通知的保密性：邀请邮件里的激活链接要带唯一校验码，防止其他人通过猜测链接获取权限。

这样一套流程下来，既解决了只有邮箱没有UID的问题，又严格遵守了所有权限约束，还能兼容系统原有的RBAC文档规则。

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