2

正如这里提到的，在具有私有文件的组的特定场景中，看起来确实没有“好的”解决方案来使用存储安全规则而不使用用户声明。虽然该线程中有一些解决方法，但对于我的情况来说不是很好的解决方案。

所以我想知道，如果我添加一个 UUID 作为文件路径的后缀（我目前这样做是为了唯一性，e.g. groups/{groupId}/images/{imageId}/imageName-{UUID}.png），它是否可以作为一种通过默默无闻的安全方式工作？（很难猜测，制作一种“私人”文件）。

我知道这并不理想，但至少暂时是这样，直到 Firebase 为这种情况实施更好的解决方案，并且能够在晚上睡得更好：P

我的想法是设置如下：

  • list：不允许（给予“默默无闻”）
  • get, create: 仅授权用户
  • update, delete: 不允许（仅适用于 Admin SDK）

我的想法有意义吗？还是我错过了什么？

4

1 回答 1

3

要求客户知道一个秘密字符串是通过默默无闻的安全，是的。

如果您允许创建访问，并期望客户端应用程序生成 UUID，这似乎是它自己的安全（或数据完整性）问题，因为客户端实际上没有义务遵循任何命名约定，而且不可能写一个规则来强制执行。

您可以通过首先调用 HTTP 函数强制客户端创建对象，让该函数创建文件（空），返回创建的路径。然后客户端可以使用返回的路径上传实际内容。

您可以改为编写存储触发器，以确保客户端事后在路径中写入“安全”内容。但最好的安全永远不会相信客户会做正确的事。

于 2019-11-29T19:41:21.687 回答