More a design question / explore options - I have a Firebase Realtime Database backed project where I have IOT-like devices (ESP32) that periodically measure environmental conditions and stores data in the database, and a flutter app that users use to associate devices with their account, view data and update device settings.
My question is about the best setup for the IOT devices - i currently have them all using a single service account to access the database and insert new readings. I'm concerned this may open up the project to security issues, and that there is no way to restrict security priveledges of a single device.
The other option is to create individual user accounts for every device (each device would have to register themselves with their own unique id). This would then allow every device to be disabled individually and operate through the security rules defined for the database, but lead to a larger number of users in the auth db and more complex iot device code.
Am I missing anything from the above? Has anyone done something similar and can offer some design insight?
i currently have them all using a single service account to access the database and insert new readings.
You should only use a service account in trusted environments, as they have full unrestricted access to your Firebase project. In all other scenarios, consider regular SDKs such as the non-privileged Node.js SDK that is great for using on IoT devices.
Related
I am looking to potentially use Firebase Cloud Messaging to flexibly add push notifications to my platform. The issue I am running into is that Firebase advises against sharing actual Firebase "projects" between "logically distinct apps."
For a normal multitenant SaaS offering, this would be a single project to represent all the client environments with end-users data being intermingled within a single location. In this case, we would logically (in our backend logic) prevent client's abilities to access each other's customer data.
The wrinkle comes in because we actually have individual, nearly identical application servers within our private AWS cluster (and databases) for each customer. We think this would work via still programmatically controlling access via each individual backend, allowing only the servers to communicate with the Firebase admin SDK.
Does anyone know if this is within the best practices? or does this violate the expected limitations?
I have a Firebase project which contains 3 different android applications. These 3 applications utilize the same data stored under Cloud Firestore. My problem is that some of the data is particular to a single app only while some documents contain data which is supposed to be read by two of the three apps. I need to write Firestore security rules to implement this.
Is it possible to restrict read/writes to a particular document based on the android package name without having to explicitly send data regarding the app-id in each request?
Is there anything else which can be used instead of the package name to uniquely identify the applications while adding firestore security rules?
So far I have been trying to restrict read and writes based on the kind of authentication used by the apps as one app uses only phone auth while the other uses both email and phone linked together. So if the email is missing but the phone is present, I know it's from the first app. Is there any better way to do it?
It's not possible exactly as you're describing. Security rules don't have any way of determining or limiting the origin of access. They just limit who can read and write what data, as determined by Firebase Authentication.
You can use the authentication provider of the signed-in user via request.auth.firebase.sign_in_provider, or any of the other per-user properties shown in the linked documentation. You can also use custom claims in request.auth.token to tag users with some privilege that allows their access to some data, which must be set using the Firebase Admin SDK on your backend.
We are developing a mobile application with a Firebase backend for a client organization. They want their organization's data hidden from the developer team. The firebase database is used by a flutter mobile application.
My current idea is to develop the app in an entirely different google account, and to swap configuration to clients google account when deploying, and deploy the cloud functions under their supervision. But there must be a easier way!
Can you guys suggest an elegant way to achieve this data privacy requirement of the clients?
What you want here is to utilize IAM roles in the project to restrict access. The client can own the project and grant limited access to the developers through roles that can be assigned.
They could give permission to deploy cloud functions without being able to read the entire Firestore database, as an example.
I'd recommend creating a second staging or "non-production" project that developers have full access to as well, since developing when you can't use the Firestore data viewer or have admin read access can be very difficult.
Is it possible to set up Firebase to allow Auth/DB access into a common/shared database instance - where that instance is setup to be a centralized storage location for some 3rd party service?
For example, let's say there's an analytics service called StackOverflowAnalytics.com .. and so anyone who signs up for that service, can add tracking to their app with some secret user key. And then all the tracking for that Key is pushed to the same Firebase DB instance. And then the user can login via Firebase auth and the rules will restrict that they can only access the node for their Key.
I'm working on a 3rd party analytics client for Android - along the lines https://mint.splunk.com - where I would like to provide users a small Java/Android library they can add to their Android project, and this will help them track different data points while their app is running. The data is made accessible by saving it to the cloud from the device.
I am currently using Firebase, but it seems in order for the Firebase Auth & DB of a given Firebase instance to be accessible - the "specific app signing key" (package name/etc combo) needs to be set in the console for that Firebase instance.
It seems sharing across across unknown apps is not possible on Firebase. And that if I want to support something like that with Firebase (and not have to go to another cloud storage option), then I need to set up some proxy REST client .. like in Java or PHP .. that can serve as a centralized access point to that Firebase instance. Just wanted to check with other folks first in case this has been encountered and perhaps there are best practices already established around this particular case. Thanks
Firebase client libraries are generally not meant to be repackaged for use in other libraries. They're meant to be used at the app level.
A unique SHA-1 key is required on Android for Authentication to work with a particular app identified by package name. This requirement will definitely become a problem for you if you want this to work with arbitrary apps, since you would have to manually enter one for each app that wants to integrate.
As far as I know it's not possible to do what you want without creating a proxy, as you mentioned. I assume that firebase has some app validation that make unfeasible to share the Auth/DB.
Maybe a solution for you is to make a proxy too to access data:
"It looks like in order to access Firebase Analytics data, you export it to BigQuery. This is working for me and is automated."
Can we implement Firebase for an android app, where I am registering user using Mobile number (Similar to Whatsapp). Users will be sent a code by server which is entered by user in android app to validate the user mobile number and registering him on the server.
Question : Can I use the above method in conjunction with Firebase Auth?
I was earlier going to use MongoDB for my project, but since Firebase has SYNC capabilities, it will be a better choice for storing data. Another good reason is as below:
If a client loses its network connection, your app will continue
functioning correctly.
Every client connected to a Firebase database maintains its own
internal version of any active data. When data is written, it's
written to this local version first. The Firebase client then
synchronizes that data with the remote database servers and with other
clients on a "best-effort" basis.
Very NEW to Firebase, just came to know about firebase (through Google 2016 IO).
https://firebase.google.com/docs/database/android/save-data
Firebase hosting is not for server side processing.
It stores static assets of your website as a world-class high availability CDN. So websites hosted here loads very fast. Even in high-availability scenarios.
So you have to do processing at other server which then connects with firebase and stores userinfo in realtime database.
Firebase has put limits on userinfo to be placed in directly for users auth dashboard.
For detailed userinfo, firebase realtime db is the way to go(from your processing backend to firebase realtime db).
Further Reading: What kind of web applications are Firebase not ideal for?