We are having different environments for one of our solution (test, preprod, prod). We've created different Firebase databases as part of single project on Firebase console. We want to have access control implemented to these databases depending on users or groups e.g. prod Firebase database will be accessible to only few users where as other environment's (test and preprod) Firebase database will be accessible to most of the users.
Are we implementing it correctly? If yes, would it be possible to configure Firebase project to have this kind of setup.
This is not the recommended way to implement different development environments. The only recommended way to separate environments is to create different Firebase projects for each one. This ensures that they each have completely isolated data, users, security rules, and so on. Adding multiple databases to the same project isn't true isolation, and could lead to problems later on.
Related
I have a CI/DC pipeline with google cloud build triggers that deploy my code to different sites depending on which branch I push to. The develop site is a live test - the final check before I merge to master, which triggers a deploy of master to the production site.
Currently, both sites use the same firebase Firestore db, and any document changed on the develop site will also be changed on the production site.
What I want to avoid is creating another firebase project to push the develop code to with a different database, because that means I need a separate set of credentials and would copy the same functions over to the new project every time I change them. That's not maintainable and is a lot of work.
What I would like is some way for the develop site to only have access to part of the firestore database, and the production site to have access to another part.
How do people do this? Is it even possible? Is there a better way? One alternative I can think of is using authentication and creating separate accounts for testing with different access permissions, but this seems a work-around and not the ideal solution.
What you're trying to do sounds like a lot more hassle than using multiple projects, which is the documented and strongly preferred solution. Putting everything in one project is a huge anti-pattern in Firebase and Google Cloud, and it will cause you more problems in the long run, in addition to increasing the risk of catastrophic failure if you manage to misconfigure something in that one project.
It's perfectly maintainable to have multiple projects like this, if you apply some scripting to automate the work. This is very common, and I strongly suggest thinking through how this would work for you.
You CI/CD pipeline could definitely check out your updates from source control and deploy them to whatever other project environments you have set up. It's very common to manage different credentials and configurations for use in CI/CD.
I am creating a firebase project. It contains two React webapps: a client facing app and a backoffice app.
I either:
create two apps in Firebase with separate configurations, and two hosting sites
or keep a single app in Firebase and use its config in both React apps, and two hosting sites
In my understanding, the apps can access the same resources either way.
What should I do?
More precisely: what is the benefit of separating Web apps in Firebase ?
If you don't intend to configure the Firebase products within each app differently, then there is not much practical difference. You would need to visit specific use cases, then ask if separate apps help or hurt that case. The use cases where separate apps would be more helpful are likely to revolve around Analytics rather than development. Analytics and its related products use the concept of an application to generate meaningful data about that app, and also create and target audiences within those specific apps.
What is the benefit of separating Web apps in Firebase?
In your case, i.e. "a client facing app and a back-office app", you probably have different user roles:
Clients who use the client facing app (maybe with different sub-roles, e.g. authors and editors or team leader and team members, depending on the business scope of your app)
Admins or Super-users, or "back-office clerks", etc... who use the back-office app.
The classical way to handle this role-based access control strategy with Firebase is to use Custom Claims.
In addition to implementing a way to grant (or not) access rights based on roles, Custom Claims also allow you to adapt your app UI depending on the user's role or access level.
This is interesting but if your app is complex and have several screens (or menus) that have different behaviors depending on the user role it can rapidly become a nightmare to hide/show parts of the UI depending on a variable. In this case it may be better to have two separate apps (in two separate Firebase projects) that point to the same (master) Firebase project.
Having two separate apps is also very interesting if different developers/development teams works on the
two apps.
For example, if I wanted to use the functions.auth.user().onUserCreate() trigger, is there any way to make it trigger different functions for different apps that are all in the same Firebase project? Is the only way to fix this to create separate Firebase projects for each app? The issue with that is that I need them to access the same database.
It's not possible to know in a Cloud Functions trigger which app a user used when they created their account. Firebase Auth accounts don't have a sense of "ownership" with respect to multiple apps per project. All apps in a project share the same users with the same permissions.
What you can do instead is have each app write something unique in your database after the account was created, then use that to determine what that user should do later on. Either that, or use different projects if your apps don't actually need to share the same set of users.
The only possibility that I think that might help you is organizing your Cloud Functions in different files, which will be then loaded per project. So, for example, in your Project Alpha, it will run the Cloud Functions from the foo.js file, while in the Project Beta, it will run the functions from the bar.js and the same logic for other projects and Cloud Functions.
This way, even though all users are sharing the same database, it will trigger the function based in the file that you requiring in your application. You can check for tips in organizing your Cloud Functions in multiple files and calling them individually, in this official documentation here:
Organize Functions
I believe this way might work for you, so, I would recommend you to check the documentation and give it a try splitting the functions in multiple files and calling each specific files, on their specific applications only.
Let me know if the information helped you!
I'm working on a product which uses Firebase as its backend. Since firebase exposes the API keys to the user so that could be a security issue. So, after doing some research I've set the database security rules along with API keys restrictions.
But, now I'm unable to use it in local development as well. I was thinking of creating another firebase project and use that as a testing environment and use the existing one as production.
Since the existing project has a lot of data and users. I want everything similar in the new firebase project as well. But I'm unable to find an efficient way to do so. Can anyone please suggest what would be the best option here? Should I create a new testing environment or is there a way to allow me to use the keys locally without it causing a security concern?
Any help would be great. Thank you for your time.
There is no specific command to replicate one project to another, but you can build the necessary functionality yourself with each product's APIs.
For porting users between projects you can use:
The Firebase CLI, which has auth:import and auth:export commands.
The Firebase Admin SDK, which has commands to list all users and import a list of users.
For transferring data between the projects, you can use the API of the relevant database to read/write the data.
Does firebase limit the amount of firebase apps that a google account can have? I'm making an app for 2 different customers and have decided to use firebase for the db functionality.
I'm slightly concerned about the above if I were to grow my business. In the event that I manage to increase my client base, , I would hate to have multiple logins to access each client project.
When it comes to billing. Can I set up my firebase to charge my account and not be project specific? An alternative to this would be if I was to create a singular project and then have multiple different apps connect to the database. However I don't think this would be possible as there would be no way for me to know who my clients customers would be. Is there anything I'm missing when it comes to this?
There is a fixed limit to how many apps you can have in a single Firebase project. Last I checked it was around 30 or so, but that may have changed.
The important thing to realize is that Firebase projects are meant to cover variants on a single "logical" app, all with a single user-base that all access the same resources.
So if you have an iOS, Android, Unity, Flutter, and Web version of the same app, you'll want to have those in the same project so that they share the same resources. If you have a specific variant of the app for admins, you'll also want to add that to the same project; again, so that it's accessing the same backend resources.
But if you have two different apps with two different user-bases, you should create a separate project for each app.