Background:
In my company, we have one firebase project which is linked to our iOS application and an internal tool(purely for our use and not the consumers). Now since the database is common to both the website and the iOS app, all the users who create an account on the iOS application automatically have access to our internal tool. I wish to allow only a handful of people or one person to have access to the internal tool.
Question:
Is there a way for me to give certain users access to the internal tool? (If it involves manually giving them access from the firebase console?)
Is there a way to make the user authentication check different for the internal tool?
Firebase Custom Claims let you specify custom access to database or tools.
You can specify an admin role to those users who should have access to the admin tool and make sure they have this role in your app's route (or route guard)
Related
I intend to develop an application using firebase authentication.
Companies will be able to sign up and in turn create accounts for their employees.
There will therefore be a "master" account which will be able to manage the operators (add them, modify them, disable them and delete them) and then the "employee" account that can use the platform.
I would like it to be possible that the master account, by entering the client id and the secret key of their oAuth server in a hypothetical administration dashboard, would make it possible for its employees to access with google.
The question is this, would it be possible to manage multiple oAuth servers (from the same provider, e.g. Google) in the same Firebase project?
Thank you in advance.
I have an application that connects to firebase cloud storage to store images and firestore to store data. I have added some security rules that require the user to be authenticated to be able to modify the data. My application doesn't allow users to connect with firebase, I use another service so I made an automatic anonymous firebase authentication at the launch of the app so that users can use the application. I thought that the computer's SHA-1 key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application. However I can build and run the application on another computer without any problem, as if anonymous allowed that? How do I secure my application?
Thanks
The configuration data used by Firebase to find your project on the servers is not a secret (see here) and can be taken from your app by anyone and then used to also make API calls against your project. There is currently now way to ensure calls to the API can only come from your app (see here).
What you instead should do is create security rules that ensure all access is authorized, no matter where the API is called from. Doing this through Firebase's server-side security rules ensures that no one can bypass these rules, not even a malicious user.
Say that you give each user their own folder in Firebase Storage. You can then use security rules to ensure each user can only read and write files in their own folder. And with those security rules in place, it doesn't matter anymore whether they use your app to access the files, or whether they call the API with your project keys and their own code:, since the access is controlled by the server-side security rules.
I thought that the computer's RSA key entered in the firebase(android) console would prevent the android application from being compiled on another machine and thus guarantee that anonymous users are on my application.
That's not really the way it works. You can't restrict Firebase Auth from working on different devices or computers. The underlying REST APIs are public and can be called from anywhere on the internet. The SHA-1 key that you enter in the console is intended to identify your app, not a piece of hardware.
I am the owner of the Firebase project.
Is it possible (for accidental data manipulation reasons) to disable write access from Firestor DB?
For instance when login in the web admin console e.g.
https://console.firebase.google.com/u/0/project/MYPROJECTID/database/firestore
to not be able to write/update/delete any documents or collections.
If you want to disable write access to web and mobile clients, you can set the security rules to disallow all writes. There is no other configuration to control client access.
For backend code, and collaborators accessing the database through the Firebase console, you can only revoke access to any services accounts that might be used to make changes using IAM.
I developed two different Flutter applications. An Admin Version and another Client Version. I would like to use the same login (auth) and access to Storage for both Apps.
It's definitely possible to access the same Firebase project from two different apps. In fact, when these apps are locally part of the same "application", that is actually an intended use-case.
A few things to keep in mind though:
Firebase Authentication does not have the concept of an administrator user. It "merely" authenticates the user, allowing them to sign in with their credentials. Any administrator logic is specific to your application, hence often referred to as an application administrator. You'll typically want to flag application administrators, for example by setting a custom claim on their accounts.
Not all functionality that the application administrator may need is going to be available in Firebase's client-side SDKs. A common scenario is that the administrator should be able to create accounts for other users, where the client-side Firebase Authentication SDKs don't support this logic. For some more information on this, and how to solve it, see Firebase kicks out current user and my answer with many links here How to create firebase admin user for authentication in java. In a nutshell: you'll have to use the Firebase Admin SDK, in a trusted environment, for some of these operations.
You then secure access to Cloud Storage by writing security rules. For some examples of securing access based on the user, see the documentation on securing user data.
I’m coding a Firebase application.
The user can only read the database and the owner can write in the database to add some content.
The owner would need an admin desktop application to upload data on the database (storage and database).
Since the application is a C++ app I would use python to communicate with Firebase.
I wanted to use Pyrebase or python-firebase but unfortunately these projects seems not to support the new database Firestore…
The rest API could work but... only with the Firestore database part...
My only way to add content to Firestore and storage is then to use the admin sdk.
I know that the C++ applicaiton will be used only on the owner computer but I’m worried about getting the service account file.
What would be the best way to use safely the service account file?
I thought to:
Encrypt the file with a password and then ask the password every
time the c++ needs to use the admin sdk (which technology would be
better for this?)
Download the service account file everytime the app needs (but where
to store it safely in the cloud?)
In order to use the Admin SDK with a project, you must have access to the service account credentials for that project. And with those credentials, you have full and unlimited access to the project. You should only distribute the service account credentials to users who should have such access, typically the collaborators on the project.
For application level administrators that are not collaborators on the project, I typically recommend setting up an administrative dashboard with a server-side and a client-side component.
The server-side component runs in a trusted environment, which for me often is Cloud Functions, but can also be a server you control, or even your development machine. This is where you use the Admin SDK to perform application administration actions, which you then expose in an authenticated end-point that client-side applications can call.
The client-side component is what the application administrator uses. For me this is often a very simple web page, but it can also be any other technology you prefer, as long as it can call the end points you exposed on the server.
The key here is that the server validates that the user that calls it is authorized to do so, before executing administrative actions on their behalf. With this approach, you don't have to give the service account credentials to a non-collaborator, and can revoke the administrator's credentials if needed.