如何构建Firebase实时数据库规则以允许向非用户发送“邀请”网址以允许访问受保护的用户数据结构？

Question

考虑以下保护的 “房间” 的数据结构在/rooms/room1：

数据：

{ 
    rooms: { 
    room1: { 
     content: "hello world", 
     authorizedUsers: { 
     "UidOfUserA": true, 
     "UidOfUserB": true 
     } 
    } 
    } 
} 

规则：

{ 
    "rules": { 
    "rooms": { 
     "$room": { 
     ".read": "data.child('authorizedUsers').hasChild(auth.uid)", 
     ".write": "data.child('authorizedUsers').hasChild(auth.uid)" 
     } 
    } 
    } 
} 

目前，UserA和用户B可以读取和写入数据到/rooms/room1。假设UserA能够允许UserB加入，因为UserA知道UserB的UID。

但是，如果用户A想要邀请尚未拥有帐户的人，则通过生成一个URL并将其发送给朋友（不一定是通过电子邮件），此设计需要扩展。

我怎样才能构建我的规则，以允许这样做？

Answer 1

一个可能的解决方案，我能想到的是：

1. 允许用户在/users/$uid/写信给自己的私人沙箱（这样他们可以设置/users/$uid/activeInviteToken的值）
2. 在房间规则扩大也允许用户写入/rooms/$room/如果他们的/users/$uid/activeInviteToken发现作为/rooms/$room/inviteTokens/

个孩子，工作流程将是：

1. 用户A增加了一个新的关键/rooms/room1/inviteTokens/（假设它是/rooms/room1/inviteTokens/inviteToken1）
2. 用户A生成与邀请令牌和房间名称的链接，并将其发送给他们的朋友;例如http://example.com/?roomId=room1&inviteToken=inviteToken1
3. 用户C报后，他们写自己的inviteToken到/users/UidOfUserC/activeInviteToken =“inviteToken1”
4. 最后，他们补充/rooms/room1/authorizedUsers/UidOfUserC，让自己获得独立的inviteToken的

虽然不是绝对必要，完成步骤4允许用户到：

• 将其activeInviteToken更改为其他内容，以便他们可以接受邀请到另一个房间，而不会丢失对room1的访问权限;和
• 过期老inviteTokens

然而，这似乎过于复杂，尤其是在将自身添加/rooms/room1/authorizedUsers前两步写涉及/users/$uid/activeInviteToken。