- This repository is a test to get cloudflare to run Firebase Firestore functionality without needing any of the custom REST apis.
- Current Status is: not working…
- Issue is that there are so many libs which are used and come from node environment.
- Using
unenv
to try to replace them; but that's not really working especially with theproxy
replacements. - Proxy replacements don't really have the functionality they are pretending to have.
- They just pretend they have it and then throw errors mostly of the "TypeError: Cannot convert object to primitive value"
- process.env.XXXX is not available and runtimeConf is problematic as well…
- So, I patched the node_modules/nodepack to support env to process.env mapping and it worked.
WARNING: the directory name test-nuxt-vuefire-ssr
for some reason has the whole thing breaking and throwing errors. Rename the main folder to test-ssr
and it works. I have no idea why this is the case but it is.
Discussion on the VueFire repo made me try to test and see how to achieve SSR on Vercel, Firebase, and localhost.
This repo is a demonstration of how to do this and how to configure the Google serviceAccount
without having the file in your repositroy and the private key exposed.
Please note that I am not a security researcher and I do not guarantee that the PRIVATE KEY does not show up in any public facing files.
From what I can tell, the way the deploy works the server side serviceAccount
is not available in the frontend javascript files.
Additional learnings about the login methods for social logins (Google Auth tested) are blow.
Generally, the workaround is that we have to set GOOGLE_APPLICATION_CREDENTIALS
to something. This is, because, there is a check in the vuefire codebase for the service account credentials based on this environment variable.
When the variable is present, other checks are performed and thus the env variables like FIREBASE_PRIVATE_KEY
are used (only if the GOOGLE_APPLICATION_CREDENTIALS
is present).
The other thing to note is that we have to link a few FIREBASE_API_ID
variables in the nuxt.config.ts
file. This is so they are configurable via environment variables but at the same time are available at build time for the frontend.
My understanding is that the frontend keys are not so "valuable" / "secret" since they are exposed to the browser anyways.
You provide all the firebase serviceAccount and front end api keys in the environment variable. See .env.vercel
for all the necessary env variables.
Note that the .env.vercel
or any .env
for that matter has to be deployed to Github for this to work! All the .env*
stuff can be setup in the Vercel UI.
In Vercel the Environment Variables
section I setup all of these:
- GOOGLE_APPLICATION_CREDENTIALS
- FIREBASE_PROJECT_ID
- FIREBASE_CLIENT_EMAIL
- FIREBASE_PRIVATE_KEY
- FIREBASE_API_KEY
- FIREBASE_AUTH_DOMAIN
- FIREBASE_STORAGE_BUCKET
- FIREBASE_MESSAGING_SENDER_ID
- FIREBASE_APP_ID
In Vercel the Build & Development Settings
are setup as follows for my env:
- Build Command:
pnpm build:vercel
- Output Directory:
.vercel
- Install Command:
pnpm install
Firebase deploy is a bit different since we have to build locally (unless you are using some github action setup but then the deploy would be more like the one on vercel).
You should also create your own .firebaserc
file. I included an example file.
So, I got it workign via:
- Run Locally:
pnpm build:firebase
- Settings in
firebase.json
and.firebaserc
(have a look into the files for pointers). - Deploy via:
pnpm deploy:firebase
For local development I was able to set it up by creating a .env.local
file which includes basically all the things the env needs to run like Vercel.
Then I have the pnpm dev
and pnpm build:local
use the .env.local
via the --dotenv .env.local
flag.
This leads to the local development connecting to the live auth / firestore for everything.
The setup with local emulators can then also be achieved, though this is not something I tested at this time.
The redirect method works fine in chrome. But there aer some issues with the login when using other browsers that are more strict with their cookies and policies? Not exactly sure.
But signInWithPopup
works fine in Safari, Firefox, and Chrome.
Whereas signInWithRedirect
works in Chrome and the others probably would work with a strict setup following the best practices from Firebase Auth layed out here.
Long story short: the easiest method is to use signInWithPopup
and not worry about the redirect method when deploying on Vercel.
On Firebase, you can easily use the redirect method since you can set the FIREBASE_AUTH_DOMAIN
in your environemnt varaible and the whole /__auth/
redirects are handled transparently by firebase.