Maybe I wasn't searching the documentation properly, but what is the recommended standard way of treating authorisation levels/classification for admin users in firebase?
Let's say in classic admin user scenario, where admin should have the access to all user accounts while normal authenticated users have write access to only specific objects.
I came accross this post but the solution using firebase secret is not good enough in this case. Firebase secret is meant to be used by server and setting up the extra server authenticating admin users and talking to firebase is certainly the option, but the complexity and programming overhead is increased.
The better option is using the security rules. Question here is - Does not this generate an extra overhead for each single read/write operation? The number of general users could be in millions while there is only handful of admins. Secondly you do not want non admin to be authenticated by management tool even though they will not be authorised to do anything.
Third option - however I don't know how would I achieve this - limit authentication to admin interface webapp only to specific admin users or set the limit for the specific domain. Let's say only {name}#myappadmin.com will be allowed to be authenticated thus I will not need to do the authorisation check before each operation. Is this even possible using only Firebase as backend?
Related
I'm developing a web app backed by Firebase which allows access to its content to only users who have signed up (using firebase auth).
my goal now is to allow unauthenticated users to view the app content but limit their usage (say, unauthenticated users will be able to view x pages per day they will have to sign up to continue their activity on the app).
I was thinking to achieve this by making an anonymous user type and follow his activity with Firestore, but then the question asked is what prevents the user from login in with a new anonymous user over and over again.
another approach that I was looking at is to limit the user actions with a session cookie, but didn't find too much information on how it works with firebase and if it's even possible.
Any suggestions on which approach you would go with?
Implementing anonymous accounts sounds like a good solution to me. Since you'll have two types of users, you can very simply differentiate them, and allow your normal users to see all the content, while the anonymous users see only restricted content.
To achieve this, you have to check each time a users signs in, if it's an anonymous user or not. If it's anonymous then allow him only to load a fixed number of pages. This can be really simply done in your app's code.
I've solved the issue with my #1 approach -
I was thinking to achieve this by making an anonymous user type and
follow his activity with Firestore
I've overcome my concern
but then the question asked is what prevents the user from login in
with a new anonymous user over and over again
by going to firebase console -> Authentication then at a bottom of the page there's advanced settings dialog, where i was able to manage sign-up quota.
this way, a user with certain IP won't be able to recreate anonymous user over and over again on a short period of time and hence abuse my app.
I'm trying to implement role-based security for Cloud Firestore. Am I understanding correctly that users retrieving stories in Google's example at https://firebase.google.com/docs/firestore/solutions/role-based-access would see the roles other users have?
How would one design against that?
I assume by using another collection & using Get?
Tad vague, but...
I am implementing role-based access in an app, but not following the example, for the very reason you mention: if a user can read a document, then they read all of the document.
My approach is a bit less direct.
The roles are stored in more secure records where only someone authorized to create the roles has access.
A Cloud Function is used for a user to fetch role information - that
way the user does not have direct access, but the secure back-end can
validate and "filter" the data appropriately (in this case, whether they are "managers" of a business property)
Another Cloud Function adds role information onto the Users account
Token as customClaims (has to be done in secure environment, not client)
Security rules validate access against the customClaims - which all
happens in a secure environment (no need to trust the browser)
More convoluted, but it does control role visibility.
I'm currently developing a web app using firebase authentication to make sure only authorized users can access the backend (e.g. firestore).
However, I don't really care about differentiating users but just want a single password based login/authentication. Meaning users come to the site, enter the password they know and then they get access to the protected data (e.g. from firestore). No need to create a own account.
However, I don't think firebase auth supports something like that.
What would likely work is just using .htaccess to protect the page and then provide users with anonymous accounts once they can access the app/page.
However, the browser popup caused by this is not nice enough for my purpose, I would prefer a nicely styled password form in the actual browser window.
What I could try is creating one account and sharing the password for that with all users (and set the email in the background). However, I'm not sure whether this works fine (e.g. multiple users being logged in at the same time on the same account).
Am I missing a simple option to implement such a single password based login shared between users?
Or is it e.g. possible to send a password to cloud functions, check it there and return an access token for an anonymous account from there to the user?
You can just create a single Firebase Auth email/password account and share the credentials with everyone. As long as you trust that each user will not share them with anyone else, and you trust that they will not maliciously overwrite each others' data, it should be fine.
CONTEXT:
In firebase settings, there's a permissions tab. This shows the users/emails that are associated with accounts that have admin access to the firebase project and console.
I could have sworn I once saw a document describing a method or some way of checking if a user account in firebase auth is also an administrator of the firebase project.
I seriously can't tell if it was in a dream (yes I dream code) or if I actually saw it. I often work late nights and fall asleep in front of my computer.
Question: Is there any way to tell if a user is also an administrator of the firebase app?
IE the user email matches an email that’s listed in the IAM/access management section of firebase as an 'owner' role?
Im currently writing an admin panel for my app, so such a feature would be very useful.
If such a thing does not exist, can anyone suggest an alternative way to manage and authorise users that are capable of logging into the admin dashboard to have control over the app? I already understand custom claims so I will use them if no better solution is suggested.
Well, using only the FirebaseAuth through your app, I don't think you can (as far as my knowledge goes). But you can easily implement the Admin SDK to manage your Custom Claims. Basically, you can use the Admin SDK and find out which "role" you want to access.
Referencing Firebase
Custom claims can contain sensitive data, therefore they should only
be set from a privileged server environment by the Firebase Admin SDK.
and
Custom claims can only be retrieved through the user's ID token.
Access to these claims may be necessary to modify the client UI based
on the user's role or access level. However, backend access should
always be enforced through the ID token after validating it and
parsing its claims. Custom claims should not be sent directly to the
backend, as they can't be trusted outside of the token.
Once the latest claims have propagated to a user's ID token, you can
get them by retrieving the ID token.
Therefore, you'll only need the FirebaseAuth implemented on your app's (client), but will need an extra implementation using a server.
Please see the Firebase use cases, they'll probably fit your needs, and you can pick the one that is "easier" for you.
It turns out it can't do what I wanted in the first place because it's only available on certain triggers.
Here it is: context.authType
https://firebase.google.com/docs/reference/functions/functions.EventContext#.authType
The level of permissions for a user. Valid values are:
ADMIN Developer user or user authenticated via a service account. USER
Known user. UNAUTHENTICATED Unauthenticated action null For event
types that do not provide user information (all except Realtime
Database).
Although it would be great if we could get this information on callable functions and firebase triggers because it would help further secure hosted backend admin apps for customer service or developers, who have high-level access to admin functions. This variable seems to not be available on callable functions but is available on newUser trigger - which is strange, because how can user signup ever be authenticated anyway?
An example is say i have a child with lots of data in it and a user wants to attack my firebase to slow it down and increase my upload limit and sets to read this child over and over again not from my app but from their own creation.
How would i prevent this from happening when the child is a public child in that it does not require a user to be logged in to be read?
Is there a way to only allow a certain domain to access a firebase so that other users cannot just access my data from their domains?
Since all the data can be read via javascript and the javascript can be changed by the user can this also happen when someone changes the code on my site. Also is this a potential problem with all databases RDBMS or non RDBMs and not just with Firebase?
You might want to check out the "anonymous" login option provided by Firebase Simple Login: https://www.firebase.com/docs/security/simple-login-anonymous.html - this lets every visitor to your site authenticate with Firebase, and you can setup your security rules such that only anonymously authenticated visitors to your site can read data.
Most production apps will employ the security rules to restrict access to their data. Learn more about Firebase security rules here: https://www.firebase.com/docs/security/security-rules.html