I have been searching about this but could not find anything. I have database rules to manage user access, but also i want to access my database from Unity Editor without affected by these rules. Is there a way?
There is no way for the Unity SDK to bypass the security rules. The only SDKs that Firebase provides that bypass the security rules are its Admin SDKs, but those are not meant to be used on client-side applications. While there is an Admin SDK for C#/.NET, if you were to use this in a Unity app (which I'm not sure is possible) - you have to be really careful to not send this app to your users.
The idiomatic approach to implement admin functionality in your app, is by implementing the specific functionality as a custom aPI on a server or in Cloud Functions, and then:
Have your Unity app call that custom API.
On the server verify who the user is, and whether they are an application admin.
Perform the necessary operation using the Admin SDK.
Related
I'm developing an android app with firebase as a backend and I heard a word named Admin SDK. I had searched for it and found it is used to manage data.
But I have a doubt that firebase provides a console webpage (console.firebase.google.com) to manage data, but why there is a separate Admin SDK?
Can someOne please explain...
The firebase admin SDK provides a simple and easy way to modify firebase settings and data using API calls.
For example, you might ask: why should you even have a regular SDK to store data? After all, you can store and save data directly from the web interface. It is, however, simply not secure or practical to have users update their own data each time using the console.
Similarly, the admin SDK is just like the regular SDK but with administrator permissions. For example, it allows you to bypass the rules set up using your firestore rules. The Firebase admin SDK is meant to be used on your backend - so you know it is running trusted software. You know that it will act the way you expect it to, unlike code running client-side that can't be trusted.
For example, let's say that you want to be able to delete a user's post if certain conditions are met. The user will make the request to your server, and it will check if the conditions are met, and then delete the post using its admin privilages. Sure you could technically automate this using firestorm rules, but those can be quite cumbersome and might not work in more complicated examples.
You can also even use it to integrate with other applications like connecting your app to a moderation tool or a curse detector that can't or shouldn't run on the client's device.
Is your question is why does Admin SDK exists?
There are several administrative tasks such as deleting users, listing collections and many more which the client cannot and should not be able to do.
Firebase Admin SDK has admin access to your Firebase project's resources.
It does not obey any security rules and can read/write any of your database, storage bucket..
That is why you must use Admin SDK in a server (or cloud function only). Although I feel Firebase Admin SDK is more useful if you use your own servers and authentication method. If you are using a custom server then:
It can be used to generate custom token so you can authenticate users using your own method (maybe legacy auth system) but still use Firebase Authentication to handle the auth tokens thereafter.
If you use your own database (and not any from Firebase), the Admin SDK can verify the ID Token sent by client and get identity of that user. Thereafter it's could be a simple if-else statement for you to decide if the user has access to the request resource or not.
I have to build an API using Firebase, and need some help with design choices. I want to be able to sell the API to users, who can then use it to build/integrate their own applications. Users will have both read and write privileges.
General information:
I'm using Firestore db with email & password authentication.
Only specifically assigned users may use the API
Each user may only access specific documents concerning them.
I've noticed 3 different ways in which an API can be provided to a user of my Firestore db:
https triggered cloud functions (https://firebase.google.com/docs/functions/http-events)
Using the SDK (https://firebase.google.com/docs/firestore/client/libraries)
Using the REST API provided by Firbase (https://firebase.google.com/docs/firestore/use-rest-api)
API requirements:
Used only by users that I specifically grant access to (email & password login)
I want to limit these users to only a couple of read/write tasks that they're able to perform.
It needs to be safe.
My current approach is:
Use the 3rd option - the REST API provided by Firebase (thereby giving users the projectId and API key)
Add authorised users to the list of authorised accounts on Firbase, and limit access using custom claims and database rules.
My questions:
It seems that https functions (option 1) are normally used in API building. Are options 2 and 3 unsafe?
What are the normal use cases of the 3 options? When should each be used and when should each be avoided?
Are there any obvious flaws in my choice of option 3?
Any other useful information about making these design decisions will be much appreciated.
Thank you in advance
TL;DL: It depends on what you want to do with this API and how many and what type of devices/users will be calling it.
Before answering your questions I will list below the advantages of each approach:
Cloud Functions:
Cloud Function is a Functions as a Service Solution, so it's also a hosting service for your API, therefore you won't have to provision, manage, or upgrade servers and the API will automatically scale based on the load. Also this option takes into account the pros of SDKs and client libraries, since your code will have to use it to connect to Firestore anyway.
SDKs and client libraries:
This is the easiest and more optimized way to reach Firestore, however, environments where running a native library is not possible such as IOT devices will be left out of your solution, so consider this while implementing this option.
Cloud Firestore REST API:
Every device properly authorized to access Firestore will be able to do so.
NOTE: For both SDK and REST API you will need to consider hosting of your API, either on Cloud Functions, as mentioned, App Engine Standard, App Engine Flex or a Compute Engine Server Instance.
All that being said, it's up to you and your API's usage and requirements to say which option is best considering the points above.
As per security, I'd say that all option can be secure if firebase rules and firebase auth are set correctly.
I'm writing an app with Flutter and Firebase (using both Firestore, Storage and Authentication so far).
Currently the app shows content from Firebase, but now I'm trying to figure out how the best way is to implement writing/editing/removing stuff in Firebase.
The goal is to have users with admin privileges.
My question is if I can build an Admin Panel inside the client app (which would be ideal), or if that's considered bad practice and I should build an Admin Panel in another app and using Cloud Functions.
For example, currently I perform Authentication (signup/register) in the Flutter/Dart code and when registering it creates a field in Firestore isAdmin = false, which I then can manually set to true (if I want) in the Firestore console. Could this somehow be an "unsafe" way of doing this?
The goal is to have users with admin privileges
Since you are using the Authentication service you already have half of the solution: with authentication you can identify each user who is using your app.
The other part is Authorization: this is normally done with Security Rules in Firebase, both for Firestore and Cloud Storage.
To be able to authorize certain users (identified through authentication) with Admin privileges, you need to know which users have the admin role in such a way you authorized them to execute the admin functions.
One possible way to identify the admin users is to have an isAdmin flag in some user documents in Firestore, as you mention in your question. There is an example of Firestore Security Rule using this approach in the documentation.
HOWEVER, you will encounter some problem if you want to use this flag (stored in Firestore) with Security Rules for Cloud Storage. At the time of writing, it is not possible to read the value of a Firestore document in Security Rules for Cloud Storage.
The solution is to use Custom Claims. You will find all the details in the doc on how to implement it in such a way it fulfill your needs.
Can I build an Admin Panel inside the client app?
Yes, you can very well do that. As soon as your security is correctly implemented (through Authentication and Security Rules, as explained above), there is nothing that prevents you to develop an Admin panel. If a user that is not admin can access the Admin panel, he/she will not be able to perform the admin actions (i.e. writing/editing/removing Firestore or Cloud Storage data).
Moreover, with Custom Claims, you can access them in the front-end to modify the client UI based on the user's role or access level (i.e. showing the pages, buttons and menu items of the Admin module only to admin users -note however that this does not prevent someone to reverse engineer your app and execute the queries dedicated to admin users: this is why it is key to correctly implement the Authentication and Security Rules parts-). See this section in the Custom Claims doc.
Should I build an Admin Panel in another app and using Cloud
Functions?
If you don't want to over-complexify your app with some logic to hide/show the Admin panel elements (based on Custom Claims, see above) you can very well build the Admin Panel in another app.
If you have specific needs/access restrictions that cannot be implemented through standard Security Rules you could very well use some Cloud Functions to check the user is an admin and to execute the writing/editing/removing admin actions (note however that while it is quite easy to interact with Firestore from a Cloud Function, it can be a bit more tricky with Storage: using the Cloud Storage Client SDKs is much easier than interacting with Cloud Storage through Cloud Functions).
You would preferably use Callable Cloud Functions, since "with callables, Firebase Authentication and FCM tokens, when available, are automatically included in requests". (See https://firebase.google.com/docs/functions/callable).
Side Note: You may be interested by this article, which details how to to create an Admin module for managing users access and roles. (Disclaimer: I'm the author).
the idea of creating an admin panel for any flutter app
The idea is for two applications with different names and they will be linked to each other with Firebase
for more details see the video from the link
https://youtu.be/d7qoff-I8BU
As I understand firebase security rules are for authenticating different types of users and provide authorization based on that, but what if my application doesn't need users to register at all? What if I just need to authenticate the application, not the users? What I mean by that is, I need to assure that particular firebase products are only accessed through an given application.
What I currently do to achieve that is, just make the security rules public assuming that the specific firebase sdk does the authentication stuff, but when I do that, I get the weird warning from the firebase console that security rules shouldn't be public. What am I doing wrong?
Another question, shouldn't we authenticate any application trying to access the firebase products even before starting the user authentication?
I also would like to learn how this is done generally (best practices) when developing serverless applications with firebase/google cloud platform products.
Firebase security rules don't support authenticating apps, only users. Authentication of an app would be pretty easy to simulate by an attacker, as all you would need is the secret compiled into the app in order to fool the rule. Even if you obfuscate the secret data, it's still just public data, and someone will figure out how to use it.
Once you ship an app to the world, you should consider everything in it to be public information, no matter how hard you might think it would be to extract that information (it's not that hard, really).
Firebase allows users to change their email client side with
firebase.auth().currentUser.updateEmail("example#example.com")
However, I would like to disable this feature entirely - obviously, I offer no way to access it on my app by default, but if an attacker managed to trick the user into install a Chrome extension or otherwise was able to access client credentials, I would always want it to fail if possible.
Is there anywhere on the Firebase auth console where I can change this functionality or a Cloud function that would stop users from changing their email?
At this moment in time, I do not see anything in the console or otherwise to disable this functionality. As it stands, there are only two Cloud Functions available for Firebase Auth events - user creation and deletion, so that would probably not be applicable to this use case either. The only thing I can think of is to just use the Admin SDK and your own API / backend to facilitate custom authentication for this scenario.