我尝试使用Firebase构建一个基于协作待办事项列表的Web应用程序。每组用户都有一个共享列表，对于有权访问特定列表的用户，他们必须已启动该组，或者被邀请加入该组。邀请将通过电子邮件发送，包括之前未使用过该网站的用户。我的目标是避免服务器端代码，并且我使用AngularJS。每个组的列表都有自己的URL。
登录该网站将使用Facebook或用户名＆amp;电子邮件。我假设有一种通过Facebook邀请其他Facebook用户的方式，但我宁愿避免使用Facebook应用程序，为了简单起见，我们希望为用户提供一个共同的邀请系统，但他们已经登录了。因此，我打算让系统像这样工作：
该群组的现有成员将输入预期新成员的电子邮件地址。 JavaScript会生成一个随机的字母数字标记，该标记用于创建邀请Firebase位置的新子项，如下所示
"invites": {
"12345ABC": "Group Name"
},
使用这些安全规则
"invites": {
".read": false,
".write": false,
"$token": {
".read": true
}
}
这样，如果您知道某个令牌，则只能阅读令牌。
电子邮件地址和以令牌结尾的群组共享列表的网址将作为子项添加到Firebase中的电子邮件队列位置。然后，Zapier（或类似）检测此子添加事件，并使用邀请URL向收件人发送电子邮件。 email_queue只能由Zapier或其他cron-type-thing读取，以保护邀请收件人的隐私。 （编辑：Zapier提供删除其操作位置的选项，并节省空间我想我会使用它。）
点击他们收到的链接的用户，一旦他们使用Facebook登录或注册了一个带有电子邮件和帐号的帐户，就会被添加到该群组中。密码。
以上是否合理还是有安全漏洞，我没有看到？
附带问题：因为我无法看到维护计数器的安全方式，是否有办法阻止具有长长电子邮件地址列表的恶意用户通过触发大量邀请来破坏系统，从而达到电子邮件提供商的发送限制？ （Zapier似乎没有提供这个）。
答案 0 :(得分：1)
是的，如果像上面那样指定，非邀请用户将无法猜出令牌。确保在邀请分支之上的任何位置都没有读取条件评估为真。
侧面回答：
我可以想到一种黑客的做法。如果您的令牌是固定长度，则可以维护另一个字段，该字段是用户要发送的令牌的分隔字符串串联。然后，要添加新邀请，首先将其附加到集合字符串，然后将其添加到邀请列表中。使用安全表达式.contains强制用户邀请令牌集合中存在新令牌。
这不是实时的做事方式，但对于小型邀请列表，它可能没问题。使用安全性强制邀请集合的大小低于特定大小。使用一些时间戳逻辑，允许用户清除列表，因为它们上次附加到令牌列表后已经有一段时间了。