[FR] Admin 'getDownloadURL' for Storage

[samtstern]

Is your feature request related to a problem? Please describe.

Download URLs are one of the most convenient ways to display content from Cloud Storage for Firebase, but right now they can only be created on the client.

There has been extensive discussion of this on the Cloud side, and their basic stance is "we don't like the Firebase URLs and we don't think you should be able to make them": googleapis/nodejs-storage#697

As a result the best documentation on how to make these URLs on the server is this massive StackOverflow answer:
https://stackoverflow.com/questions/42956250/get-download-url-from-file-uploaded-with-cloud-functions-for-firebase/56010225#56010225

Describe the solution you'd like

A simple getDownloadURL() method in the Node.js Admin SDK

Describe alternatives you've considered

None

Additional context

None

[spotvin42]

I am also struggling with this and the community as well, we can see it on stackoverflow...

I've created my own way to get one following the described method in your shared link.

I think it's not right as one commenter from Google said, but I don't see another way?

https://stackoverflow.com/questions/70563169/resizing-images-already-on-google-storage-locally-through-sharpjs-and-keeping-u

Thank you in advance for supporting this issue!

[ArnabXD]

I found an interesting article regarding this

https://www.sentinelstand.com/article/guide-to-firebase-storage-download-urls-tokens

[samatcolumn]

Well I've got a new job but still running into this same issue, we'd love a simple way to generate download URLs for objects from our backend Node.js server. Right now we can only do this on our frontend.

I do understand there are many workarounds but we'd like the solution to be the same on frontend and backend, not have different types of URLs depending on where they were generated.

[willbattel]

Yeah it's a bit ridiculous that we can't directly access the tokened URL from the Admin SDK. We want the token feature so we have the ability to revoke, as opposed to just making everything public. Ideally we would keep the URL in the associated Firestore document that we're already fetching on the client so we don't need to make extra round trip requests that needlessly slows down the application. I'm not sure why there has been so much pushback from Google on this- it feels like a major handicap to their Storage product that only the client SDKs can access the URL.

[samatcolumn]

We're using relatively old versions of Firebase (JS v8.3.3, Admin v9.4.2) so YMMV but I found that this workaround seems to get me what I want on the backend:

  const storage = admin.storage();
  const ref = storage.bucket(`gs://${bucket}`).file(pathToFile);
  const [metadata] = await ref.getMetadata();

  const token = metadata.metadata.firebaseStorageDownloadTokens;
  const link = `https://firebasestorage.googleapis.com/v0/b/${bucket}/o/${encodeURIComponent(
    pathToFile
  )}?alt=media&token=${token}

But it scares me that firebaseStorageDownloadTokens is undocumented and I can't figure out where that comes from or if it's guaranteed to exist in all situations (I assume not). I'd love to hear a Googler's perspective on this workaround at least.

[atif7865]

@lahirumaramba is this being looked at internally? Any updates?

[willbattel]

Looks like they are open to it in principle but are looking to change the mechanism internally this year so I guess we'll just have to wait and see what that means...

See: #2036 (review)

[tonyjhuang]

Hi, Firebaser here. Sorry for the radio silence and thanks for the continued interest in this FR. @willbattel is correct in that we are looking to offer alternatives to download urls in the future as there are some interesting security implications of this feature that makes it unideal in security-critical applications.

That being said, while we can't provide an estimated timeline on when it will become available, @maneesht is actively working on adding getDownloadUrl functionality to the admin SDK to bridge the gap in the meantime.