Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recycling download tokens is problematic (storage-resize-images) #323

Closed
nicoqh opened this issue May 22, 2020 · 3 comments
Closed

Recycling download tokens is problematic (storage-resize-images) #323

nicoqh opened this issue May 22, 2020 · 3 comments
Labels
in-progress A fix or resolution is in progress type: bug Something isn't working

Comments

@nicoqh
Copy link

nicoqh commented May 22, 2020

[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:

  1. 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).

  1. 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

@russellwheatley
Copy link
Member

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.

@Ehesp
Copy link
Member

Ehesp commented Jun 15, 2020

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).

@chrisjacobs91
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in-progress A fix or resolution is in progress type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants