基于默默无闻的火灾存储安全

Question

正如前面提到的here，在具有私有文件的组的特定场景中，似乎没有真正“好”的解决方案来使用存储安全规则而不使用用户声明。不过，在这个线程中有一些解决方案，但对我的情况来说不是很好的解决方案。

因此，我想知道，如果我在文件路径中添加一个UUID作为后缀(我目前是为了唯一性( e.g. groups/{groupId}/images/{imageId}/imageName-{UUID}.png)而做的)，它是否可以作为一种通过模糊的方式来实现安全？(这将是非常困难的野蛮猜测，作出某种“私人”文件)。

我知道这并不理想，但至少是暂时的，直到Firebase为这个场景实现了更好的解决方案，并且能够在晚上睡得更好:P

我的想法是设置这样的东西：

• list：不允许(给出"obscurity")
• get，create：only users
• update，delete：不允许(只使用Admin )

我的想法有意义吗？还是我漏掉了什么？

Answer 1

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

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

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

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