了解Firebase存储令牌
我在试图理解令牌在Firebase存储中是如何工作的。
每当我的web应用程序将图像上传到FS，它就会在其公共URL中添加一个令牌。问题是，每当您将同一图像文件上传到web应用程序的另一个部分时，您似乎没有得到另一个文件，而是得到了已经上传的文件url的不同令牌，从而为以前注册的图像显示呈现403错误。
有办法解决这个吗？
storageRef.put(picture.jpg);
uploadTask.snapshot.downloadURL
// returns something like https://firebasestorage.googleapis.com/v0/b/<your-app>/o/picture.jpg?alt=media&token=09cb2927-4706-4e36-95ae-2515c68b0d6e
<img src="https://firebasestorage.googleapis.com/v0/b/<your-app>/o/picture.jpg?alt=media&token=09cb2927-4706-4e36-95ae-2515c68b0d6e">
如果用户重复这个过程，并在应用程序的另一个部分上传相同的picture.jpg，而不是在Firebase存储中获得一个全新的副本，文件将被一个以新令牌结尾的URL覆盖；说12345。
所以：
<img src="https://...picture.jpg?alt=media&token=12345"> // New upload renders fine
<img src="https://...picture.jpg?alt=media&token=09cb2927-4706..."> // But old upload breaks because of wrong url
暂时还没有答案
-
我有一个关于网址中的“令牌”的问题（ https://firebasestorage.googleapis.com/v0/b/someapplication.appspot.com/o/images/sample.png?alt=media 从文档中，它说它返回一个“长寿”的下载网址https://firebase.google.com/docs/reference/js/firebase.sto
-
对于我们的应用程序，我们需要能够提供团体访问文件。每个用户可能拥有大量的组，因此使用“自定义令牌”解决方案是没有意义的（无论如何，这是非常尴尬的）。 我发现，Firebase的存储安全规则非常有限。主要问题是，我们将组定义保留在存储安全规则无法访问的Firestore中。 为了克服这个问题，我们决定在每个上传文件的元数据中包含一个“令牌”，组中的任何人都可以访问这个令牌。当他们下载一个文件时，他们
-
我试图建立一个使用firebase数据库和存储的社交媒体应用程序。下面是预期的流量。 > 用户上传存储在当前用户文件夹中的firebase存储中的个人资料图片和存储在firebase数据库中的URL以便快速访问。（很好） 用户发表他们的想法。这样可以在数据库中保存用户信息，如邮件、用户名和配置文件图像URL。（很好）。 现在的问题是，如果一个用户更新了他或她的个人资料图片，这将覆盖firebase
-
所以我想知道，如果我将一个UUID作为后修复添加到文件路径（我现在这样做是为了唯一性，)，它是否可以作为一种通过模糊来实现安全的方法呢？（这将是非常困难的野蛮猜测，使某种“私人”文件）。 我知道这不是很理想，但至少在Firebase为这种场景实现更好的解决方案之前，这是暂时的事情，并且能够在晚上睡得更好：p 我的想法是设置如下内容： null
-
我对block blob存储是如何工作的有点困惑，所以我对这些限制是如何工作的有点困惑（从我读到的内容来看，大多数人甚至不会接近这些限制，但我仍然想知道它是如何应用的）。我一直在读这篇文章 限制似乎是这样的 块BLOB存储文本和二进制数据，最多约4.7TB。块BLOB由可以单独管理的数据块组成。 或者block blob是否意味着如果我有img001并且它是1GB，它将被分离成块，并且限制为50,