Firebase 私有规则不适用于存储答案

【问题标题】：Firebase private rule not working for storageFirebase 私有规则不适用于存储
【发布时间】：2016-10-07 02:29:44
【问题描述】：

我正在尝试允许用户将文件上传到 firebase 后端，我使用的是这个规则：（存储在我端填写）

service firebase.storage {
  match /b/<storage>/o {
    match /{allPaths=**} {
        allow write, read: if false;
    }
  }
}

这只是为了让我看看它是否会阻止用户访问我打开的文件。但是如果我去链接，我可以看到图像就好了。

为什么这条规则没有阻止用户查看它？谢谢。

【问题讨论】：

【解决方案1】：

从 Firebase 存储下载文件有两种不同的方式：

如果您通过第一种方法下载，我们会在允许下载之前检查安全规则。这是向用户或用户组 ACL 文件的安全方法。

如果您通过第二种方法下载，这些 URL 是公开的、不可猜测的 URL，因此任何人都可以访问它们，并且仅受 URL 末尾令牌的不可猜测性保护。这种方法非常适合与您的应用程序之外的用户共享文件（例如 Google 相册，您想将照片发送给您的家人，但又不想让他们下载应用程序来执行此操作）。

听起来您正在使用第二种方法，如上所述，它不检查安全规则。如果您想制作文件，可以在 Firebase 控制台中删除下载令牌，或者永远不要与任何人共享这些 URL。

【讨论】：

我们有什么方法可以将这些 URL 设为私有，还是 Google 只是为了安全而默默无闻？这对我来说似乎很可疑。
@DevShadow 下载 URL 用作功能令牌：如果您拥有该令牌，则您可以访问该文件。许多流行的照片共享应用程序使用某种形式的功能令牌（通常采用签名 URL 的形式）。
能力令牌的关键是它们足够不可猜测。在我们的例子中，我们使用 UUID 代表一个随机选择的 128 位数字，这意味着有 2^128 = 3.4e38 种不同的可能性（并且在您第一次尝试时猜测它的概率为 1/3.40282367e38 ~=0）。即使有人猜测每秒 100 万张照片（31.5T 照片/年）：在有人用尽搜索空间之前，您还有 1.0e25 年的时间。即使是每秒 1B 个请求，它仍然是 1.0e22 年。
这与现代密码学使用的一般原则（用非常大的素数代替）相同：从技术上讲，您可以分解所说的素数，但实际上没有办法有效地做到这一点。