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.
Related
I am having trouble in writing firebase permissions. I want those users if authenticated only write to users section and Everyone else should be able to read or write to any section of the database. Is there any way that I can define rules for every table default to true and restrict only user section to be authenticated or I have to explicitly write rules for every table.
PS. It would be great if someone could guide me what rules should I implement for an app with features for sending and receiving a message with the following structure:
-Chat
-Friends
-Users
-message_notifications
-messages
-notifications
/* Visit https://firebase.google.com/docs/database/security to learn more about security rules. */
"rules": {
"Users":{
"$uid":{
".read": true,
".write": "auth.uid == $uid"
}
}
}
}
Is there any way that I can define rules for every table default to true and restrict only user section to be authenticated?
Once a user has access to data at a certain level in your database, they have access to all data under that level. You cannot revoke this permission on a lower level. So there's no way to give a user access to all data at the root, and then exclude one node.
What you can do is use the $ wildcard rules to create two types of top-level nodes:
{
"rules": {
"Users":{
"$uid":{
".read": true,
".write": "auth.uid == $uid"
}
},
"$others": {
".read": true,
".write": true
}
}
}
With the above rules, users can:
Only read the /Users/$uid node of a user if they know the UID of that user.
Can only write their own /Users/$uid node.
Can read and write all other data.
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>.
In Firebase security rules how can you stop hackers running a script for signup to your website? bare in mind I need them to be able to signup externally on my homepage so I cannot say they need to be logged in.
I know the basic settings from reading Firebase security documentation but I'm worried its not secure enough, especially if someone new my firebase app url to write or read to the database.
In addition it would be good to know the basics I should have so I can check if I do have those.
Currently I have these settings:
{
"rules": {
"users": {
".read": "auth != null",
".write": true,
".indexOn": ["uid", "region"]
}
}
}
Users can write as I need them to sign up but cannot read unless then are logged in. Also have some indexes for performance reasons.
This is where my knowledge stops.
Thanks in advance!
You want to allow users to write, but only to their own user entry. That's actually easy to do with rules:
{
"rules": {
"users": {
"$uid": {
".read": "auth != null && auth.uid == $uid",
". write": "auth != null && auth.uid == $uid"
}
}
}
}
This says /user/{$uid} can only be read or written by a user who is signed in, and who's user ID matches the {$uid} part of the path. Take a look at the rules quickstart for more.
My .validate rules don't seem to get executed when I'm deleting data from Firebase. Is this a bug or intentional behavior?
In general, .validate rules are used to define what the data should look like if it exists. They are intentionally not run when the data is deleted. You should instead use .write rules to make decisions about whether the write (or delete) should be allowed.
For example, consider these rules for securing a simple chat room, where users can create new chat rooms but only delete ones for which they are the owner:
{
"rules": {
".read": true,
"$room": {
".write": "auth != null && (
(!data.exists() && newData.child('owner').val() == auth.uid) ||
(!newData.exists() && data.child('owner').val() == auth.uid))",
".validate": "newData.hasChildren(['owner', 'name'])",
"name": {
".validate": "newData.val().length > 10"
},
"messages": {
".write": "auth != null"
}
}
}
}
The .write rule is used to decide if a user has permission to create / remove a chat room, and the .validate rules are used to define what a chat room should look like if it exists.
If the .validate rules were run on deletes, you could never delete a chat room (since both .validate rules would fail). Hence the decision not to run .validate rules on deletes.