A few months ago, it seemed like when you stored an image in Firestore, if you called up the image in the Firestore storage UI, when you check the file, you'd see metadata about the storage object including it's MD5 hash. Now that seems like the hash is gone, or perhapps I misremember? I know that somewhere on the firebase console you could see the MD5 hash of a stored image, but I can't locate it now. Also there was some version of the URL which would return the metadata for the file, not the image itself, but I can't find that either.
Anybody have an idea?
Related
Right now, everytime I upload an image file to firebase storage, I get an url that looks like this:
https://firebasestorage.googleapis.com/v0/b/my-project.appspot.com/o/some-folder%2Ffile_name.jpg?alt=media
And I'm storing the full URL in my Firestore docs for the object that uses that image.
If I know that it will never change, I could save just the last part: /some-folder%2Ffile_name.jpg?alt=media
But I don't know if the first part could change for future uploads.
Since I'll be rebuilding the full URL on client, if the first part do change for future downloads, it will break my code.
Should I stick to storing the full URL? Or is it safe to assume that the first part of the Firebase Storage API will always be the same?
Firebase gives no written guarantee that nothing will change for that URL. The only "safe" thing to do is store the entire URL. Or, store the path and call getDownloadUrl every time you want to manufacture a new URL.
I can specify the source If I want to get data from firestore, either default, from server or from cache like this:
query.get(Source.CACHE)
say I normally get 50 documents if using the code above.now I want to delete one specific document from that query in cache, so I want to get only 49 documents.
how to do that ? is it possible ?
You don't have direct control over the status of the internal cache maintained by the Firebase SDKs. You can't delete or invalidate specific items.
The cache is completely managed by the SDK. The SDK determines when documents should be added or removed, based on whether or not they are in sync with the server.
You can use the SDK to delete a document, which will remove it from cached results. But that delete will eventually get synchronized with the server, and that's a permanent change.
If you have steps that show that the internal cache is somehow buggy or inconsistent with the contents of the server, then file a bug report with Firebase support that shows now to reproduce the issue.
I want to delete one specific document from that query in cache, so I want to get only 49 documents.
There is no way you can specify that in a delete() operation. If you want to get that behavior, your device should be offline. In that way, Firestore will delete the record from the local cache. But please note, that once you regain the connection, your record will also be deleted from Firebase servers. While online, there is no way you can have a deleted document in the cache and not from Firebase servers.
I'm trying to determine the best way to reference a Firebase Storage (Google Cloud Storage) file in a direct-read database like Realtime Database or Cloud Firestore. Since a read operation to this database does not benefit from a backend that can issue tokens and cache image URLs, it is not clear to me what the most performant way is to store these references.
I have come up with a few options and none of them are a clear winner.
Store a path like /images/foo.jpg to the database, and use Storage Client SDK to generate a tokenized path with storage.bucket().getDownloadURL("/images/foo.jpg").
Pros: Secure & simple.
Cons: Network call for every single image you want to display hurts performance considerably.
Store a tokenized path like https://firebasestorage.googleapis.com/v0/b/storage-bucket-823743.appspot.com/o/images%2Ffoo.jpg?alt=media&token=c6da1e33-f3ff-41e2-a6f0-bdb475a2f6d9 with a super long TTL.
Pros: No extra fetch on the client.
Cons: long string stored in expensive RTDB. What if that token is revoked by mistake? The database is now broken.
Store a path like /images/foo.jpg to the Database and use public storage rules. Reconstruct into a custom static URL like https://firebasestorage.googleapis.com/v0/b/storage-bucket-823743.appspot.com/o/images%2Ffoo.jpg?alt=media
Pros: Tiny database use, no extra client fetch, explicit public access, no token to lose.
Cons: URL encoding is super flaky, Storage could change their URL format and we'd be out of luck.
So, those are the options I've come up with, and there may be more. Any suggestions for how to solve this issue? The issue is unique because the Firebase databases don't have the benefit of a custom server to handle a token/caching layer to resolve this problem.
There is no single "best way" to store these paths. It all depends on your use-case, your preferences, and the context in which you're implementing it.
I typically use :
If I need access to the files to be secured, I store the image path (like in your #1), and then use the Firebase SDK to access the file.
If I don't need access to the files to be secured, I store the image path and the download URL. This way I can find the image easily based on the path, and use the download URL in non-secured clients.
The con's you mention for these are simply not affecting me. I'd recommend you take a similar approach, and report back when the problem actually occurs.
Haven't started development yet, but I just want to ask if there would be some security issues if I created a qr code that will directly download something from the firebase storage, will there be some authorization stuff needed? still choosing wether to store it from google drive or firebase storage(payment capacity reasons)
If you encode the download URL from Firebase Storage into the QR code, then anyone with the QR code can read the file. That is because the download URLs from Firebase Storage are publicly readable, but unguessable.
If you instead encode the path to the file into the QR code, then that file can only be access by a user that is signed in to Firebase and for whom the security rules you have configured allow read access to the file.
From what you described you're looking to use the first option with download URLs. It's hard to say what security issue you're asking about, but just be aware that in that case anyone with the QR code will know the download URL, and can thus read the file (or share that URL with others, so that they too can read the file). If that is not what you want, you'll need a more advanced scheme, which typically starts with being able to identify your users.
I have a situation where in Firebase Storage users store their avatar to /users/{uid}.jpg
If I then use the Storage API to get the download URL and display the image, it ends up being very slow to make the first request because the download URL is not cached anywhere.
So my solution is to get the DownloadURL when the user uploads the image and store that in Firebase allowing the client image provider to automatically cache the image which speeds up loads considerably.
However, there is one problem with this solution.
If a user replaces their avatar, the old link becomes broken instead of updated. I believe this is because a new token is generated each time something is uploaded for security reasons but these are of no benefit to me.
So my question is twofold:
1) How can I allow a user to upload an avatar to a path that is dedicated to them such as /users/{uid}.jpg, get a bare download URL that can be cached by the client, and have that URL remain the same even when the file changes at /users/{uid}.jpg
2) If this is not possible, what is the normal way to solve this issue?
Download URLs are opaque. The contents of the actual URL itself is an implementation detail of the system, and it's not supported to dig around in its contents. The URLs can't be dissected or composed.
You can use a storage trigger with Cloud Functions to automatically generate a signed URL whenever something changes in your storage bucket.
So instead of serving from a hard-coded URL, simply retrieve the URL from an updated value in the datastore (or any data storage system). Every time the user updates the avatar, simply store the new URL in the datastore and you can query for it when you need it.