I am developing an app with firebase and angular and angularfire. I would like to implement a
"invite collaborators" feature in much the same way as firebase itself implements collaboration - that is, the app user can enter an email address to invite collaborators which would send an email and generate an "inviteToken", just as is done when inviting collaborators in firebase itself.
I understand that security rules (to limit collaborator access) and schema design( a /collaborators 'folder' ? ) are one aspect, which can be accomplished using native firebase and angular. My question is how to best implement the invite email and the 'inviteToken'? What would be the most expedient way to implement such an invitation feature? Could it be done using native firebase? Or would one need to implement separate, server side code (nodejs?)? Perhaps someone from the firebase team can opine based on how firebase itself implements collaboration.
You can implementation collaboration by hashing the email address of the user you want to share a particular piece of data with, and storing it under a permissions field.
For example, let's start with a path /items/item1 that is owned by 'user1':
{
"items": {
"item1": {
"data": "foobar",
"permissions": {
"user1": true
}
}
}
}
You'd set the security rules for the data as follows:
{
"rules": {
"items": {
"$item": {
".read": "data.child('permissions').hasChild(auth.uid)",
".write": "data.child('permissions').hasChild(auth.uid)"
}
}
}
}
Now when 'user1' wants to share 'item1' with 'user2', they will simply write the value 'user2' and set it to true under the permissions key. You can extend the structure of the 'permissions' key to be as granular as you want (eg: collaborators can only read, but owner can both read and write, etc.)
In practice, you may want to use hashes of the user's email addresses, for example. Also take a look at Simple Login for an easy way to authenticate your users (once authenticated, the auth variable used in the security rules above are automatically set for you).
Related
i have a serious Question. I am developing the Security Rules for my Firestore Database. So what if someone decompiled my App, stole the GoogleInfo.plist, added this file to his Project, and creates multiple Accounts with it? I mean in the security rules you have to:
allow create: if request.auth != null;
So he could add a new Document every time he adds an FirebaseUser Account.
How to solve and secure this?
Are there other options like sign in with custom field at example:
I create a document ID.
and so we check in the Firestore rules:
match /document/{myDOC}
allow write: if request.auth.code == myDOC;
So what I mean here is, if I can set additional Information to the Request of my App, and check if the additional Information is Equal to the myDOC;
Thanks!!
This is all working by design. There is no "security" information in GoogleInfo.plist. It just contains data that instructs the Firebase SDK on how to find your project and its resources. Without that data, your app would know nothing about your project.
To secure your database, you will need to design your database to allow for per-user security, then write rules that determine which authenticated users can read and write which documents, as suggested in the documentation.
It's not possible to send extra information along with a query for the purpose of security. You should depend on what Firebase auth provides in request.auth in the rules language.
See also: Is it safe to expose Firebase apiKey to the public?
https://firebase.google.com/docs/auth/admin/custom-claims
Firebase Admin SDK allows you to define custom attributes on user accounts.
admin.auth().setCustomUserClaims(uid, {admin: true}).then(() => {
// The new custom claims will propagate to the user's ID token the
// next time a new one is issued.
});
When you are writing your rules, it is possible to check these custom attributes.
{
"rules": {
"adminContent": {
".read": "auth.token.admin === true",
".write": "auth.token.admin === true",
}
}
}
But as it is stated in the docs, you should consider these points:
Use custom claims to store data for controlling user access only. All other data should be stored separately via the real-time database or other server side storage.
Custom claims are limited in size. Passing a custom claims payload greater than 1000 bytes will throw an error.
I'm kind of stymied on my Firebase read/write rules. I wish I had a way to set break points as it's checking authentication (there isn't a way, is there?).
My question is fairly simple and I feel like I should be able to understand it better. I feel like most of stems from not understanding fully the rules. This information is for a simple way to view products online and the owner needs to be able to add products. So I want the world to be able to read and people who log in be able to write.
My data looks like:
app
Users
email: xxx#xxx.com
product
0
name: pizza
And my rules:
{
"rules": {
"product":{
".read": true,
".write":"root.child('Users').child(auth.uid).child('email').val() === 'testuser#test.com'"
}
}
}
and I don't have a great grasp of what this means. I really just want to say, if the user is logged in, allow write capabilities. I would have hoped I could so something like ".write": "auth" meaning that if auth exists (user is logged in) then let him write. But I'm clearly not fully understand how the rules work. I'm using simple email/password authentication.
How are these rules tested and how do I pass parameters to them?
I'll try to explain your .write security rule, which is:
"root.child('Users').child(auth.uid).child('email').val() === 'testuser#test.com'"
This is indeed not the easiest rule to start with and the Firebase documentation admittedly dives into the deep rather quickly.
After I log on to my application with twitter, my code will get an authData variable that tells it:
authData
uid: "twitter:4511241"
provider: "twitter"
id: "4511241"
There might be a few more properties, but this should be the gist of it. The authData will typically contain a child object with properties that are specific to the provider, so in this case twitter and you can normally find some pretty interesting stuff there. Such as in the case of Twitter, the user's twitter name.
authData
uid: "twitter:4511241"
provider: "twitter"
id: "4511241"
twitter:
userName: "puf"
email: "puf#twitter.com" // note: this is just an example email address,
// it doesn't exist (as far as I know)
This object is made available to my code, it is not stored anywhere in Firebase by default.
In your security rules, you can check against the same structure. But only a minimal subset of the information is available here, just enough to identify the user. The Firebase documentation for the auth object names these properties:
provider | The authentication method used ("password", "anonymous", "facebook", "github", "google", or "twitter").
uid |A unique user id, guaranteed to be unique across all providers.
With these properties, we can already allow a specific user write access to our data. Like I said in my comment to your answer:
".write": "auth.uid = 'twitter:4511241'"
This will allow me to write data when I log on with my #puf twitter account. But unfortunately it doesn't allow me to check against more user-friendly properties, such as the email address.
A common practice is to create a top-level Users node in your Firebase and add all the information for all the users under that node, identified by their uid. So in my case above:
Users
twitter:4511241
userName: "puf"
displayName: "Frank van Puffelen"
email: "puf#twitter.com"
github:913631
userName: "puf"
displayName: "Frank van Puffelen"
email: "puf#github.com"
I left the provider and id off here, since they don't provide much value for the example
When you know a user's uid, you can look up his additional information in this node. And that is exactly what the security rules you had before does:
"root.child('Users').child(auth.uid).child('email').val() === 'testuser#test.com'"
So this will look from the root of your Firebase, for a node called Users, then for the uid of the logged in user and under that his/her email address.
The cool thing about checking for a specific email address, is that it is not tied to the user's provider. So no matter whether the user is logged on with twitter, github, facebook or some other supported provider, as long as they used the same email address for each account, they will be able to write the data.
Doing the below seemed to do the trick. If the auth variable exists, then allow write abilities. Due to me not fully understanding these rules, I have to wonder if this is running against the current user or if it's checking to see if any user is logged in.
{
"rules": {
"product":{
".read": true,
".write":"auth !== null"
}
}
}
Is there a way to restrict users from registering firebase email/password accounts so that new users can't sign up? I have a small app that only a few admins need to have access to(which I've manually created in the Firebase admin) and the way it's setup right now it seems like anybody could inject a little javascript and register an account.
Firebase Simple Login is an abstraction built on top of Firebase Custom Login for convenience. When using the email / password authentication, it's worth keeping in mind that this is just creating a mapping between that email and password, and automatically generating authentication tokens for use in your security rules.
In your specific case, if all of the "admin" users have already been created, you can achieve the behavior you're looking for through security rules. For example, if you want to only allow read / write access to your Firebase data tree to authenticated users in that list, try writing top-level read / write security rules that require that user to be in the "admins" list:
{
".read" : "auth != null && root.child('admins').hasChild(auth.uid)",
".write" : "auth != null && root.child('admins').hasChild(auth.uid)"
}
Those rules above ensure that the user is authenticated (via auth != null) and require that the authenticated user's id is in the list of admins (root.child('admins').hasChild(auth.uid)).
The last step is to actually make those users admins, by writing them to the admins subtree. Let's say you have users 1, 4, and 7 to make admins, update your data tree to reflect the following:
{
...
"admins": {
"1": true,
"4": true,
"7": true
}
}
As a result of this, even if other users are able to generate new email / password mappings using Firebase Simple Login, those mappings will have no impact on your application as it is restricted using security rules.
#RobDiMarco provided a great answer, but it has a flaw.
The rule root.child('admins').hasChild(auth.uid) will pass, in case auth.uid will be an empty string.
You can test this in Firebase Database Security Simulator, clearing out uid field ({ "provider": "anonymous", "uid": ""}).
This rule root.child('admins').child(auth.uid).val() === true will not pass with an empty uid.
You can also turn off new user registration by adding a cloud function that deletes new users upon registration. See this answer:
How to prevent new user registration on Firebase?
It seems like the only thing that can be changed is the password (via auth.changePassword()). How do I let a user change their email address or display name?
The firebase Auth object is pretty simple but it will provide you the user id generated when the user authenticates to your system. You would then take this user id and map it to a Users location where you can store additional information such as display name.
For example, after the user has authenticated and you have your auth object with id value, you could do:
new Firebase('https://your_fb_url.firebase.io').child('users/'+id).set({email: email, name: name}, function(err) {})
You'd want to have read/write rules setup on that location to only allow the authenticated user to see & make changes. Something like:
{
"rules": {
"users": {
"$user": {
".read": "$user == auth.uid",
".write": "$user == auth.uid",
}
}
}
}
6/12/2015 - UPDATE - Below is Outdated
As for changing the actual login e-mail (for Firebase Simple Login Web), that I'm not so sure about. I know they provide a change password method but I haven't seen any documentation about a change login/email method.
The underlying code for firebase simple password doesn't appear to include any methods for changing the login e-mail address associated with the account. The changePassword method eventually performs a jsonp call out to /auth/firebase/update with the email, old password, and new password.
I'd hate to suggest using a combination of removeUser/createUser to remove the old account, create a new account, and update any user id associations you have you in your app - but I don't see a straightforward "changeEmail" method. The remove/create route would require the user to enter their password again - though that's a pretty common practice for updating logins these days anyway.
6/12/2015 - UPDATE - New API
Firebase has moved away from Firebase Simple Login as a separate module and now the core Firebase 2.x library has authentication related methods baked in. Including a method to change the e-mail account used for the authWithPassword methods.
See updated 2.x docs for changeEmail()
This is my first foray into Firebase & nosql, I come from a SQL background.
Using Simple Login Security Email/Password, how do I limit access to data in Firebase? For example, some user will have access to create a business object (users, customers, categories, etc), others won't. Is there a way to attach a list of permissions to the "auth" variable?
There isn't a way to attach permissions directly to the auth variable (or at least that doesn't seem to be an intended strategy). I'd recommend creating a collection of users organized by auth.uid and you can keep whatever kind of permission attributes you want in there, such that your security rules might something look like this (untested):
{
"rules": {
".read": true,
"users": {
".write": "root.child('users').child(auth.uid).child('role').val() == 'admin'"
}
}
}
Where role is an attribute belonging to all objects in your users collection.
UPDATE
See comment below:
"There isn't a way to attach permissions directly to the auth variable" This changed in 2017. You can now attach custom claims to an auth profile, which are available in security rules. See bojeil's answer and the Firebase documentation for custom claims. – Frank van Puffelen
Firebase launched support for role based access on any user via custom user claims on the ID token: https://firebase.google.com/docs/auth/admin/custom-claims
You would define the admin access rule:
{
"rules": {
"adminContent": {
".read": "auth.token.admin === true",
".write": "auth.token.admin === true",
}
}
}
Set the user role with the Firebase Admin SDK:
// Set admin privilege on the user corresponding to uid.
admin.auth().setCustomUserClaims(uid, {admin: true}).then(() => {
// The new custom claims will propagate to the user's ID token the
// next time a new one is issued.
});
This will propagate to the corresponding user's ID token claims.
You can force token refresh immediately after: user.getIdToken(true)
To parse it from the token on the client, you need to base64 decode the ID token's payload: https://firebase.google.com/docs/auth/admin/custom-claims#access_custom_claims_on_the_client
You can upgrade/downgrade users as needed. They also provided a programmatic way to list all users if you have recurring scripts to change a users' access levels: https://firebase.google.com/docs/auth/admin/manage-users#list_all_users
Looking at this again a year later "Custom Tokens" may be a better option.
https://www.firebase.com/docs/security/guide/user-security.html#section-custom