[READ] Step 1: Are you in the right place?
...
[REQUIRED] Step 2: Describe your configuration
- Extension name: storage-resize-images
- Extension version: 0.1.8
[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):
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 resize
const metadata: 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
Discussions: #34, #140
[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,
firebaseStorageDownloadTokenswas deleted from the metadata object before the resized image was uploaded.#279 removed this deletion, resulting in
firebaseStorageDownloadTokensbeing 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
firebaseStorageDownloadTokensis 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:
firebaseStorageDownloadTokensis 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.getDownloadURLis 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