I have the following form of database
Database
users
<UID>
user
<other information>
I am trying to read all my users in admin mode and only allow individual users to access their own information.
I am trying this rule:
"users": {
"$uid": {
".read": "auth != null && (auth.uid == $uid || root.child('users').child(auth.uid).child('user').child('admin').val() == true)",
".write": "auth != null && !newData.child('admin').exists() && (auth.uid == $uid || root.child('users').child(auth.uid).child('user').child('admin').val() == true)"
},
".indexOn": ["userid"]
},
I am doing the following query and I see the following error:
allusers = $firebaseArray(firebaseDataService.root.child('users'));
permission_denied at /users: Client doesn't have permission to access the desired data.
Any idea what I am doing wrong here ?
When you attach a listener to /users, the Firebase server checks whether you have read permission on /users. If not, it rejects the listener.
This is a common source of confusion for developers new to Firebase. Coming from a SQL/relation mindset, we are used to use security to perform (server-side) filtering. In Firebase you cannot use security rules to filter data.
I'll add a few relevant links below for further reading:
rules are not filters in the Firebase documentation
Restricting child/field access with security rules
the Firebase blog post on why denormalizing is normal
an article on airpair about data structuring
a great summary from a while ago on the firebase-talk group
Related
my current firebase realtime security rules are like below
{
"rules": {
"users": {
".read" : true,
".indexOn": ["email"],
"$user_id": {
".read": true,
".write": "auth != null && $user_id === auth.uid"
}
}
}
}
they translates as only the authenticated user can write the data to his own node under users/
However, we have admin users who should be able to modify the data of non admin users.
The way we identify admin users are a user property isAdmin which is true for admin users. so the sample data with a admin and non admin user looks like below
{
"users": {
"kldjjfjf" : {
"name": "vik", "isAdmin": true
},
"lfllfomr": {
"name": "neeti", "isAdmin": false
}
}
Please advise what is the best practice to handle this kind of usecases? doing a .write true will solve it but then it will make it open to anyone to modify anyone's data.
The simplest ways I've found to allow Administrative access is to:
Use a custom claim for admins
Use a whitelist of admin UIDs
Use a custom claim for admins
You can add custom claims to Firebase Authentication user profiles with the Admin SDK. Claims are custom key/value pairs that you determine the meaning of yourself. The first example from the documentation shows setting a claim called admin to true, for example with the Admin SDK for Node.js:
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.
});
Once a custom claim is set, it is transported to the client when it signs in, and is also available in security rules. You can check the above with:
".write": "auth != null && ($user_id === auth.uid || auth.token.admin === true)"
Use a whitelist of admin UIDs
A simple alternative is to store a list of UIDs in your database of users with specific privileges. For example, you could have a top-level Admins list:
Admins
uidOfVik: true
uidOfPuf: true
The above means that you and me are admins. You then check for those in the security rules:
".write": "auth != null && ($user_id === auth.uid || root.child('Admins').child(auth.uid).exists())"
Here's an alternative:
Firebase security rules only apply to clients connecting normally to the application.
If you have your own back end (I can't assume that, because Firebase is made for Serverless computing) then it can connect to the application with the admin SDK, which bypasses the security rules.
Alternatively, you can make a separate application for your admin users, that will connect to firebase using the admin SDK.
More information: Firebase Documentation - Firebase Admin SDK
I want users of my app to have access to see profile of other users that is accessed via real-time database. I'm referencing to db via
ref.once('users/'+uid, snapshot => snapshot.child('users/'+uid).val())
Rules i have:
{
"rules": {
"users": {
".read": true,
"$uid": {
".write": "$uid === auth.uid"
},
},
}
I don't get why i can't access users/:uid even though simulator gives success message by ticking read and running simulation on <firebaseURL>/users.
If i set ".read": true" under rules it does allow me to read the data, but that may bait me later on if i would want to implement stuff that i don't want to be available to unauthorized users.
Edit (solution):
The problem was with referencing to firebase. Instead of firebase.database.ref('users') I was referencing too root itself by firebase.database.ref().
That reference caused to apply default read/write rules.
You could give ".read": "auth != null" to allow all authorised users to read data under users object and prevent unauthorised users from reading it.
I have a question for my own sanity. Below is one portion of my firebase rules
{
"rules": {
".read": "auth != null",
".write" : false,
"users": {
"$uid": {
".read": "auth != null && auth.uid == $uid",
".write": "auth != null && auth.uid == $uid",
"tokens": {
".write": "(newData.val() < data.val())"
}
}
},
...
If I understand correctly the rules state that:
ALL users must be auth'ed in order to read ANY node
ALL user can NOT write to any nodes
Specific to the User node:
In order to read from your own data, you need to be auth'ed and you can only read your own node
In order to write to your own user data, you must be auth'ed and you can only write to your own node
The user/token node can only be decremented and never increased by any user
Can someone confirm my assumptions/understandings reading Firebase security rules documentation.
Also does anyone have any good articles or helpful tips on using the simulator!?
An important concept with the security rules is that read/write rules "cascade" down the tree. This is discussed briefly in the documentation. That means that as you read your rules from top to bottom, the first rule that grants access takes precedence over any rules specified below it on children of that location.
Addressing each of your items:
ALL users must be auth'ed in order to read ANY node (YES)
ALL user can NOT write to any nodes (non-auth'ed users can NOT write to any nodes)
Specific to the User node:
In order to read from your own data, you need to be auth'ed and you can only read your own node (YES)
In order to write to your own user data, you must be auth'ed and you can only write to your own node (YES)
The user/token node can only be decremented and never increased by any user (see below)
In your current rules, the check for smaller token is not effective because the prior rule granting write access to an auth'ed user overrides it. You also need to address the case where there is no existing token value. My suggestion for fixing that is to use a .validate rule. The documentation recommends:
Used once a .write rule has granted access, to ensure that the data
being written conforms to a specific schema.
{
"rules": {
".read": "auth != null",
".write": false,
"users": {
"$uid": {
".read": "auth.uid == $uid",
".write": "auth.uid == $uid",
"tokens": {
".validate": "!data.exists() || (newData.val() < data.val())"
}
}
}
}
}
As for the Simulator, I don't know of any user guide, but have managed to learn how to use it by experimentation. It's a very effective tool for understand the rules.
Here are a few cases of using the Simulator:
When you open the Simulator, Authenticated is off, which simulates a non-authenticated user. To simulate a read, click on the read button, enter a location: e.g. /users/xyz/tokens, and click on Run. You will see a red X on the lines of the rules that forbid that operation. To simulate an authenticated read, click on the Authenticated button and, for convenience, enter a simple user UID, like "Frank". Now enter location /users/Frank/tokens, click on Run and observe that the read succeeds.
You can do similar tests for writing, entering a location, auth settings and value.
I am little bit confused about setting permissions in Rules section of my Firebase database.
I am working on an app (which is a Book actually) and the app must be updated by only one person with this email address: someone#gmail.com. Therefore the rest of people, either authenticated or not, must not be able to modify the contents, but they are allowed to read.
If you look at the Firebase Security Rules API, you'll see that the user's email address (if there is one) is made available via auth.token.email.
So to grant write access to the entire database to the user with the someone#gmail.com email address and read access to everyone else, you could define rules like this:
{
"rules": {
".read": true,
".write": "auth !== null && auth.token.email === 'someone#gmail.com'"
}
}
Said rules would grant read access to everyone. If you wanted to grant read access only to authenticated users, you could use:
{
"rules": {
".read": "auth !== null",
".write": "auth !== null && auth.token.email === 'someone#gmail.com'"
}
}
I've been looking on the docs but I couldn't figure out how to prevent duplicated entries if the email exist on a record. There are my current rules
{
"rules": {
"users": {
"$uid": {
// grants write access to the owner of this user account whose uid must exactly match the key ($uid)
".write": "auth !== null && auth.uid === $uid",
// grants read access to any user who is logged in with an email and password
".read": "auth !== null && auth.provider === 'password'"
}
}
}
}
And my record format is:
Thank you very much
Unfortunately you cannot do this type of query in firebase due to it's distributed nature. In general, arrays are extremely tricky and you can read about their limitations in the context of Firebase here.
The way I see it you have two options, you can index your users "array" by the email itself, or you can keep a completely separate object holding all the emails in the system to check against when you make an insert. My suggestion would be the first, set the user object to users/<email>.