Firebase Setup: Firestore, Auth & Storage
Este conteúdo não está disponível em sua língua ainda.
FireCMS talks to your own Firebase project — it never proxies or copies your data. That means the CMS can only do what your Firebase project lets it do, so a few things need to be switched on before the admin panel becomes useful.
This page covers the four pieces FireCMS actually depends on, and what each one unlocks:
| Firebase service | What FireCMS uses it for |
|---|---|
| Firestore | Every collection, document and form in the CMS |
| Web app config | The credentials object you pass to the CMS |
| Authentication | Who can open the panel, and their role |
| Storage | File, image and video fields |
Firebase’s own docs cover each service in general; everything below is specific to running FireCMS against it.
Enable Firestore. A default project denies every read and write until you change the rules — FireCMS will connect and show nothing.
// everything private by default match /{document=**} { allow read, write: if false; } // then open up what an editor needs match /products/{id=**} { allow read: true; allow write: if request.auth != null; }
Firestore
Section titled “Firestore”Enable Firestore in your project. FireCMS reads your existing documents to infer collection schemas, so if you already have data, you already have a CMS — there is no import step.
A default Firestore project ships with rules that deny all reads and writes. Until you change them, FireCMS will connect but every collection will look empty.
The simplest rule set that lets an authenticated editor work is:
rules_version = '2';service cloud.firestore { match /databases/{database}/documents { match /{document=**} { allow read, write: if request.auth != null; } }}That is fine for a private back-office, but rules should match your domain. A more realistic set — public product reads, authenticated writes, and users restricted to their own document — looks like this:
rules_version = '2';service cloud.firestore {
// everything is private by default match /{document=**} { allow read: if false; allow write: if false; }
match /databases/{database}/documents { // anyone may read products; only signed-in users may write match /products/{id=**} { allow read: if true; allow write: if request.auth != null; } }
// users may only touch their own user document match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }}Web app
Section titled “Web app”In your project settings, create a Web app. Firebase gives you a configuration object — that object is what you pass to FireCMS.
Authentication
Section titled “Authentication”Enable Authentication so users can get past the login screen. FireCMS builds its roles and per-collection permissions on top of Firebase Auth, so this is also where access control starts.
Vite serves the dev server at http://127.0.0.1:5173 by default, and Firebase Auth
rejects sign-ins from domains it does not know. Add that URL to the authorised domains
in the Firebase console, or run the dev server on http://localhost:5173 and authorise
that instead.
Storage
Section titled “Storage”Enable Firebase Storage if you want to use the CMS file, image or video fields. FireCMS writes uploads to the project’s default bucket.
Next steps
Section titled “Next steps”With Firestore, Auth and Storage in place, your Firebase project is ready:
- Self-hosted quickstart — scaffold and run the CMS locally
- FireCMS Cloud quickstart — connect the project and skip the hosting
- Firebase App Check — lock the panel down once it is live
