After giving a try to Firebase authentication modules (surprised to such handy utils), I played around the storage part of Firebase, and very satisfied on how it is designed. Pros Firebase Storage is designed specifically for , , and . scale security network resiliency ( Read more ) Every file uploaded is backed by , which scales to . Scale: Google Cloud Storage petabytes Files can be secured to specific users or sets of users using Storage Security Rules. Security: Uploads and downloads are automatically retried in the case of poor network connections, so you don’t have to keep track of them yourself. Network Resiliency: Cons When your product have its own auth system, it is not easy to config ACL on firebase. Everything is well encapsulated on firebase SDK, of course storage access control rules is included. 1. Setup storage bucket key in the Project You must add your bucket to your Firebase SDK configuration. 2. Setup Rules Storage Security Rules must first specify the Cloud , (via ) which rules are evaluated against. storage match /b/{bucket}/o There are simply four types : , , and we are going to use public as an example ( ). default public user private, less authentication problem to demo service firebase.storage { match /b/{bucket}/o { match /{allPaths=**} { allow read, write; } }} 3. Coding Cloud Storage allows developers to quickly and easily upload files to a bucket provided and managed by Firebase. Google Cloud Storage Since the default Google App Engine app and Firebase share this bucket, configuring public access may make newly uploaded App Engine files publicly accessible as well. Be sure to restrict access to your Storage bucket again when you set up authentication. Also, Firebase supports both and object upload. Blob File Reference: — https://firebase.google.com/docs/storage/web/start — https://firebase.google.com/docs/storage/security/start#sample-rules — https://firebase.googleblog.com/2016/07/5-tips-for-firebase-storage.html
Share Your Thoughts