You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a previous version, firebaseStorageDownloadTokens was deleted from the metadata object before the resized image was uploaded.
#279 removed this deletion, resulting in firebaseStorageDownloadTokens being copied from the original object to the new (resized) object.
One issue is that download tokens should be unique per object, ref #34 (comment):
I chatted with the Cloud Storage for Firebase team about firebaseStorageDownloadTokens. The field should be unique per object. If it isn't set on an object, it will be set automatically by the Cloud Storage for Firebase api when getDownloadURL() is called.
My use case illustrates the problem: Files are not public, but I display the resized versions using getDownloadURL(). The resulting download URL contains the token, which can be used for the original file as well. But the original image should not be accessible! Also, all thumbnails use the same token, which is equally problematic.
It seems to me that copying firebaseStorageDownloadTokens is a workaround to make sure the resized images are displayed in the Firebase Console (which won't work without a token), but that tokens are meant to be unique for good reasons.
Two possible solutions:
Let the extension generate a download token (tokens are UUIDv4) an add it to the resized image's metadata map. This works perfectly, and images are viewable in the Firebase Console as well. Example:
// `objectMetadata` is from the original image that we want to resizeconstmetadata: any={contentDisposition: objectMetadata.contentDisposition,contentEncoding: objectMetadata.contentEncoding,contentLanguage: objectMetadata.contentLanguage,contentType: contentType,metadata: {
...(objectMetadata.metadata||{}),firebaseStorageDownloadTokens: "123-TEST-TOKEN",// Should be a call to uuid4()}};
firebaseStorageDownloadTokens is a Firebase concept, so I don't see any downsides with using it in an official Firebase Extension.
What about people who want to overwrite the original image and keep the same download URL (ref #268)? This could be a config option (if "replace original file", then reuse the old token, otherwise generate download tokens for each resized version).
Alternatively, upload the resized image without a download token, then immediately use the Firebase Storage SDK to create a download URL by calling getDownloadURL() on the file reference. This method will create a token and save it as metadata if a token doesn't already exist. getDownloadURL is not a Cloud Storage concept and the method doesn't exist on the Admin/Storage SDK, so the extension would need to pull in the client SDK, and I haven't checked if this is possible. This solution is functionally equivalent to solution 1, but it requires more changes and one more dependency (the client SDK). Its only advantage over solution 1 is that it doesn't "bypass" getDownloadURL() (but again, this is an official Firebase project, and a previous version of the extension also did).
Background info:
Commit that reversed the deletion of firebaseStorageDownloadTokens: #279
Hey @nicoqh, thanks for the head's up and possible solutions! Very informative. I'm sure the Firebase Extension's team will consider the options available on solving this issue.
Hi all - we've decided to go with the following approach:
If the image being resized contains a firebaseStorageDownloadTokens field, then the resized images will be created with a new token (rather than copying the parent).
Hi - late to the party, but wanted to know if you had considered allowing the resized images to have the same token as their parent as a setup option on the function?
I have added this in myself, but whenever I update to the latest extension version, it overwrites my custom code.
[READ] Step 1: Are you in the right place?
...
[REQUIRED] Step 2: Describe your configuration
[REQUIRED] Step 3: Describe the problem
In a previous version,
firebaseStorageDownloadTokens
was deleted from the metadata object before the resized image was uploaded.#279 removed this deletion, resulting in
firebaseStorageDownloadTokens
being copied from the original object to the new (resized) object.One issue is that download tokens should be unique per object, ref #34 (comment):
My use case illustrates the problem: Files are not public, but I display the resized versions using
getDownloadURL()
. The resulting download URL contains the token, which can be used for the original file as well. But the original image should not be accessible! Also, all thumbnails use the same token, which is equally problematic.It seems to me that copying
firebaseStorageDownloadTokens
is a workaround to make sure the resized images are displayed in the Firebase Console (which won't work without a token), but that tokens are meant to be unique for good reasons.Two possible solutions:
firebaseStorageDownloadTokens
is a Firebase concept, so I don't see any downsides with using it in an official Firebase Extension.What about people who want to overwrite the original image and keep the same download URL (ref #268)? This could be a config option (if "replace original file", then reuse the old token, otherwise generate download tokens for each resized version).
getDownloadURL()
on the file reference. This method will create a token and save it as metadata if a token doesn't already exist.getDownloadURL
is not a Cloud Storage concept and the method doesn't exist on the Admin/Storage SDK, so the extension would need to pull in the client SDK, and I haven't checked if this is possible. This solution is functionally equivalent to solution 1, but it requires more changes and one more dependency (the client SDK). Its only advantage over solution 1 is that it doesn't "bypass"getDownloadURL()
(but again, this is an official Firebase project, and a previous version of the extension also did).Background info:
Commit that reversed the deletion of
firebaseStorageDownloadTokens
: #279Discussions: #34, #140
The text was updated successfully, but these errors were encountered: