I'm currently building an open-source microservice that makes use of Firebase Database, Hosting & Functions. The plan is to pack everything in a single binary and distribute this. So users will have a hazzle-free, "bring your own Firebase project"-solution. They'll just have to download the binary and their Firebase secret key and can then create a user and deploy the service via CLI.
The problem is, that firebase-tools require a $FIREBASE_TOKEN when deploying via its API. So users would have to install firebase-tools in order to be able to generate that token and they would also have to store it (or re-generate it frequently).
Since I would like to provide a hazzle-free experience, I'd rather generate that token myself with the help of the secret key.
The question is: is this even possible? And if yes: how??
My workaround for this is to reflect the login- and logout-commands of the Firebase-CLI on my own binary's CLI. So the user won't have to install another tool.
To get the refresh_token I then read the data from the firebase-tools-configstore, that is located in the user folder. This feels a little dirty, like accessing a private API. But I couldn't come up with a better solution. And it works.
Related
When configuring CI for a Firebase project, I often see references to either a FIREBASE_TOKEN generated with firebase login:ci or a service account key that (I think) is generated by default for each project.
For my particular use case, I want to do the following:
run online tests (with Firestore) against my test project when running npm run test during my CI build
deploy that code to a different prod project if tests pass
Which one should I use?
I would recommend you to use the FIREBASE_TOKEN. As usually, tokens are better to use, as you can quickly cancel or renew in any issue that you might have it, as well it's easier to manage them a service account and to insert them in the code.
Besides that, the official Firebase documentation - Use the CLI with CI systems - indicates and teaches how to use it with the token, so it seems that indeed, using the token is the best and easier option for you to implement.
I need to set a secret in my functions config but I want to make sure, that this secret cannot be accessed by anyone, even if the person has access to the firebase project and thus the cli itself.
What I mean by that is, if I set the secret in my cli, I can then retrieve this secret firebase functions:config:get. There are people who might have access to the firebase cli of this project that should not be able to access this secret.
Is there a way to achieve this?
The functions configuration you're referring to is only saved on the local machine. It will not be checked into source control. Other developers who use the CLI in the same project, but on different machines, will not be able to see that configuration.
The configuration will be available in the deployed code, however. If each developer needs a fully isolated configuration at runtime, they should each have their own project to work with.
So, the issue is the following: I need to access Travis CI API to get the build status for our organization repositories. The issue here is that using personal GitHub token to generate Travis API token is an overall bad practice, cause the user can leave the organization, or his access rights could be revoked for particular repositories.
The idea was to create a GitHub App, install it to the organization and let the app generate Travis CI tokens using its privileges, and grab the build status programmatically.
I created an app and tried to perform such a trick with the authentication, but it did not work for me.
Any ideas/suggestions are welcome.
As per the answer from the Travis support, it is currently not possible to create API tokens with anything except the personal GitHub token.
The best solution is to create the less-permissive GitHub token, ideally from the GitHub user-account that is used for automation.
I have an open-source project that uses two separate Firebase projects for a test environment and the production one.
Ultimately, I want to have other developers be able to pull down the project and actually be able to run it WITHOUT me needing to give each individual developer access.
I see a number of solutions in this question: How to add collaborators to a Firebase app?. Those all seem to require each person's email.
I understand why it maybe isn't a thing, but I am wondering if there is a way to just give access to everyone for only the test project so that contributing is super low-friction. Something similar to Firestore database rules that allow read/write in a public fashion to get started for testing.
I've tried making a new IAM account in the Google Cloud Console, and I think that partially worked for the Firebase Cloud Functions access to Admin SDK, but my collaborators get hung up trying to run firebase use <test-firebase-project> saying that they don't have access.
I see a lot of other config options for IAM, but nothing sticking out to me for this public access scenario.
Can anyone confirm this either is or isn't a thing?
Thanks!
EDIT
To add some more detail to my project...
I am using Authentication, Firestore, and Cloud Functions. The only js package I will use is the Auth one, which will be loaded from a CDN (so I believe that doesn't apply to my question).
I want to give access to people to run the Cloud Functions locally. There is a pre-build step that I have made in vanilla Node that calls a Cloud Function (running locally), which uses the Firebase Admin SDK to call my Firestore database. I then write that response to a JSON file that my front end uses.
When my collaborators pull down the project, and install the Firebase CLI, when they try to serve the Cloud Functions locally, they get hit with a "no access" type of error. I was trying to resolve this by adding a service account into the /functions directory, but apparently that didn't help.
My collaborators don't need access to the console at all. I basically just need them to be able to run the Cloud Function locally (and make sure they can't access my production Firebase project).
I am happy to add more detail, but I kind of feel like I am just rambling. Thanks again.
There is no way to grant everyone contributor access to your Firebase console. You will either have add each individual user, or create your own dashboard that uses the API to show the relevant data.
Is there a way to delete an app via Firebase CLI?
Our CI creates a temporary Firebase app for a feature branch (based on the CI build number), and then runs tests on it. At the end it needs to delete the app. I'm not entirely sure how this is done. firebase disable:hosting just disables hosting and does not delete the app. This is similar to how we would have used Heroku review apps or Heroku forked apps. A similar CI workflow can also be achieved on Google App engine via versions.
Any pointers would be much appreciated.
The correct command is firebase hosting:disable, which make your site offline. You can not remove your project, instead you can overwrite it by creating a new one with firebase init.
More info here https://firebase.google.com/docs/cli/.
There is currently no public API to delete a Firebase backend.
The recommended practice is to use the same database for testing and (if needed) put each run in its own node under the root. So instead of creating/deleting a new database, you're just create/deleting a node in a single database.
Using the command firebase use <alias> --unaliasand then delete the project from the console https://console.firebase.google.com/
Check before the list of commands with the command -h