如here所述，在具有具有私人文件的组的特定情况下，似乎确实没有使用“存储安全规则” 不使用用户声明的“好的”解决方案。虽然在该线程中有一些变通办法，但对于我的情况来说并不是很好的解决方案。
[因此，我想知道，如果我将UUID作为后缀添加到文件路径中（目前我为实现唯一性而为e.g. groups/{groupId}/images/{imageId}/imageName-{UUID}.png做此操作），它是否可以作为一种通过掩盖安全性的方法？ （很难猜测，做出某种“私有”文件）。
我知道这并不理想，但至少暂时是这样，直到Firebase为这种情况实施更好的解决方案，并能够在晚上睡得更好：P
我的想法是设置类似的内容：
list：不允许（给出“晦涩感”）]get，create：仅授权用户update，delete：不允许（仅对于Admin SDK）]我的想法有意义吗？还是我错过了什么？
要求客户端知道秘密字符串是通过默默无闻的安全性，是。
如果您允许创建访问，并期望客户端应用生成UUID，这似乎是其自身的安全性（或数据完整性）问题，因为客户端实际上没有义务遵循任何命名约定，并且它没有可以编写一条规则来强制执行该规则。
您可以通过首先调用HTTP函数，让该函数创建文件（空），并返回创建的路径，来强制客户端创建对象。然后，客户端可以使用返回的路径将实际内容上传到其顶部。
您可以编写一个存储触发器，以确保客户端在事发后的路径中写了一些“安全”的内容。但是最好的安全性永远不要相信客户端会做正确的事。