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 scale, security, and network resiliency (Read more).
- Scale: Every file uploaded is backed by Google Cloud Storage, which scales to petabytes.
- Security: Files can be secured to specific users or sets of users using Storage Security Rules.
- Network Resiliency: Uploads and downloads are automatically retried in the case of poor network connections, so you don’t have to keep track of them yourself.
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 storage, (via match /b/{bucket}/o) which rules are evaluated against.
There are simply four types : default, public, user and private, we are going to use public as an example (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 Google Cloud Storage bucket provided and managed by Firebase.
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 Blob and File object upload.
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