I'm struggling to come up with the best way to structure part of my database and its associated security rules.
I have chat groups, and users can be added to those groups at any point. When users are added to a group, they should be able to retrieve only the messages sent after that. It shouldn't be possible for them to retrieve any messages that were sent before they (the users) were added to the group.
My first approach wrongly assumed that security rules would apply only to the data being queried.
Simplifying it for this question, I had the following structure:
{
"groups": {
"-Kb9fw20GqapLm_b8JNE": {
"name": "Cool people"
}
},
"groupUsers": {
"-Kb9fw20GqapLm_b8JNE": {
"3JzxHLv4b6TcUBvFL64Tyt8dTXJ2": {
"timeAdded": 1230779183745
},
"S2GMKFPOhVhzZL7q4xAVFIHTmRC3": {
"timeAdded": 1480113719485
}
}
},
"groupMessages": {
"-Kb9fw20GqapLm_b8JNE": {
"-KbKWHv4J4XN22aLMzVa": {
"from": "3JzxHLv4b6TcUBvFL64Tyt8dTXJ2",
"text": "Hello",
"timeSent": "1358491277463"
},
"-KfHxtwef6_S9C5huGLI": {
"from": "S2GMKFPOhVhzZL7q4xAVFIHTmRC3",
"text": "Goodbye",
"timeSent": "1493948817230"
}
}
}
}
And these security rules:
{
"rules": {
"groupMessages": {
".indexOn": "timeSent",
"$groupKey": {
".read": "root.child('groupUsers').child(auth.uid).child($groupKey).child('timeAdded').val() <= data.child('timeSent').val()"
".write": "!data.exists() && root.child('groupUsers').child(auth.uid).child($groupKey).exists() && newData.child('from').val() === auth.uid",
}
}
}
}
With that, I figured I could retrieve the messages for a particular group like so:
var myTimeAdded = /* already retrieved from the database */;
firebase.database()
.ref('groupMessages/-Kb9fw20GqapLm_b8JNE')
.orderByChild('timeSent')
.startAt(myTimeAdded)
.on('child_added', /* ... */);
But like I said, that was a wrong assumption. Any suggestion on how I could achieve this?
Read rules are enforced at the location where you attach a listener.
So in your case that is groupMessages/-Kb9fw20GqapLm_b8JNE. If your user has read permission there the listener is allowed. If the user does not have read permission, the listener is rejected/cancelled.
This means that rules cannot be used to filter data. We often refer to this as "rules are not filters" and it's one of the most common pitfalls for developers who are new to Firebase's security model. See:
the section rules are not filters in the Firebase documentation
previous questions about Firebase that mention "rules are not filters"
By themselves your rules are not wrong: they only allow access to each specific child if it's not too old. They just don't allow you to run a query on groupMessages/-Kb9fw20GqapLm_b8JNE anymore.
The common way to work around this is to have a separate structure (commonly called an "index") with the keys of the items that your query would otherwise return. In your case it looks like that might turn into a index for each user with the keys of all messages after they joined.
But I'll be honest, it sounds like you're trying to use security rules in a SQL way here. It seems unlikely that the user isn't allowed to see older messages. More likely is that you don't want the user to be bother by the older messages. In that case, I'd just solve it with a query (as you already have) and remove the ".read" rule.
Related
I face an issue : I want the user of my web program to write and delete data in firebase only if he knows where it is and I don't understand what rules have to apply to that.
For instance, my user has an id which is '785475' and I want to only give him access to '/data/785475'. How do I do that please?
Do I have to use authentification?
Thanks in advance and please have a nice day!
In Firebase security rules permission cascades. So in your model and requirement, it is important that the user doesn't have read access to /data, as that means they could read /data and all nodes under it.
To the trick is to only grant them access to the individual child nodes of /data:
{
"rules": {
"data": {
"$any": {
".write": true
}
}
}
}
With the above nodes, a user can delete any existing node that the know the key of, but they can't read (or query) the entire /data node to determine those keys.
To only allow them to overwrite existing data, and not create any new nodes, you can do:
{
"rules": {
"data": {
"$any": {
".write": "data.exists()"
}
}
}
}
For more on this, and other examples, check out the Firebase documentation on new vs existing data.
Assume that we have two nodes: "items" and "sales". How can I write a firebase db rule to prevent any item being deleted if it is related in another node. If a user wants to delete ("items\i01") it should not give permission because it is a relation under ("sales\s01\i01")
"items": {
"i01": {
"name": "item1"
},
"i02": {
"name": "item2"
},
}
"sales": {
"s01": {
"itemKey": "i01",
"price": "45"
},
"s02": {
"itemKey": "i02",
"price": "60"
},
...
}
Security rules can check whether data exists at a known path, but cannot perform searches for data across (a branch of) the JSON tree. So in your current data structure, there is no way to prevent the deletion of the item based on it still being referenced.
The typical solution would be to add a data structure that you can check in security rules to see if the item is still referenced anywhere. This would pretty much be an inverse of your current sales node, which tracks the items in a sale. The inverse node would track the sales for any item:
"sales_per_item": {
"i01": {
"s01": true
},
"i02": {
"s02": true
}
}
You will need to make sure that this new structure (sometimes called an inverted index) is updated to say in sync with sales, both in code and in security rules.
With that in place, you can then prevent deletion of an item that still has references with:
{
"rules": {
"items": {
"$itemid": {
".write": "!newData.exists() && !newData.parent().parent().child('sales_per_item').child($itemid).exists()"
}
}
}
}
As an alternative, you can consider moving the deletion logic into a Cloud Function, where you can do the "check for orders with the item" in code, instead of in security rules.
I also recommend reading these:
How to write denormalized data in Firebase
Patterns for security with Firebase: combine rules with Cloud Functions for more flexibility
Patterns for security with Firebase: offload client work to Cloud Functions
Sorry if the title was confusing, I'll do a better job explaining here.
I was reading up on the Firebase security documentation and came across this page: https://firebase.google.com/docs/database/security/quickstart?authuser=0. Specifically I was looking at the "Sample Rules" -> "User" section which contained the following code:
// These rules grant access to a node matching the authenticated
// user's ID from the Firebase auth token
{
"rules": {
"users": {
"$uid": {
".read": "$uid === auth.uid",
".write": "$uid === auth.uid"
}
}
}
}
Assuming I understand this correctly, you will only be able to read YOUR data under the "users" node, and nobody else's.
So in my app I need to retrieve some data about a "friend" (friend count, username, posts they've made, etc) which is stored under my "friend's" user id in the "users" node. So it looks like this:
{
"users": {
"friend_uid": {
"friend_count": 10,
"username": "john",
"posts": [
"message": "post1"
],
"age": 18,
...
}
}
}
How can I do this based on the permissions above? If this is such a common task (getting some basic information about your friend), then why do a lot of tutorials show that you should set the rules to what I pasted above?
How do developers get the data they need? Do they have 2 nodes, "users" and "private_users", where in "users" they store all of the public information for retrieval from anyone, and "private_users" is where they store all the private info about the user and set stricter read/write rules?
Or do they set database rules on the individual attributes like age, name, etc?
You've basically given the answer yourself... You could either separate the data nodes and add an object with public data and one with private data, where both would have different rules for access.
For the public data node of a user, you of course wouldn't set the rules to allow complete public access when reading, but also limit it to users that are in the friend list.
Another option is to set rules on the individual properties, but this makes the rules quite big and harder to maintain, as every additional parameter needs to be added to the rules manually.
An additional thing I see when looking at your data is the missing data denormalisation. Each user object contains a list of messages/posts done by that user. So if you query a user in users/UID, you'd fetch the whole object including the possibly millions of posts/messages. So you should definitely exclude those from the user objects.
For the past few weeks i've been exploring Firebase and its features to build a web app, but I've kind of ran into a wall when it comes to security rules.
I've build a data structure on Firebase but I'm not sure if it follows best practices (if it doesn't, feel free to suggest anything different about it):
{
"groups" : {
<GROUP_KEY>
"name": "",
"rels": {
"users": {
<RELS_USERS_KEY>
"key":"" (USER_KEY)
},
"notes": {
<RELS_NOTES_KEY>
"key":"" (NOTE_KEY)
}
},
"isPrivate": true
},
"users": {
<USER_KEY>
"email": "",
"rels": {
"friends": {
<RELS_FRIENDS_KEY>
"key":"" (USER_KEY)
}
},
},
"notes": {
<NOTE_KEY>
"title": "",
"description": "",
"rels": {
"files": {
<RELS_FILES_KEY>
"key":"" (FILE_KEY)
}
}
},
"files": {
<FILE_KEY>
"mode": "",
"url": ""
}
}
The application flow is as follows:
The user signs up: a key is created on "users";
Is redirected to "Groups" view, where he should be shown only
groups that have his ID in RELS > USERS, or that has
"isPrivate":"false";
As the user creates a Group, a new group is added with his ID in RELS > USERS;
Entering the Group view, he should only see notes that are in RELS > NOTES for that group.
The rest of the logic follows the same principle, and I believe that if I can get through the first hurdle of understanding the Firebase security rules and applying them to this case, I can get through the rest.
I've tried a couple of rules, but I can't seem to get any feedback at all from the web application, debugging this has been a trial-and-error process, and its not really working.
Could someone help me at least understanding the logic behind it ? I've read all of their tutorials but they all seem very shallow with no deeper examples on complex structures.
Thanks for the help.
EDIT
I've added the debug:true flag to the login (thanks #Kato), but I'm still getting no feedback on the rules. With the rules as below, I still enter the "Groups" view, but get no feedback on the console, and the logged-in user sees groups he shouldn't:
{
"rules": {
"groups": {
".read": "data.child('rels').child('users/' + auth.user).exists()",
".write": "data.child('rels').child('users/' + auth.user).exists()"
}
}
}
As for the rules I've tried, they were countless, but this is the most recent one (still no feedback).
Maybe I'm missing something ?
Thanks again.
Rules cascade. That is, if any rule allows read, then you cannot revoke it later in a nested child. In this way, you can write rules like the following:
"$record": {
// I can write the entire record if I own it
".write": "data.child('owner').val() === auth.uid",
"foo": {
// anybody in my friends list can write to foo, but not anything else in $record
".write": "data.parent().child('friends/'+auth.uid).exists()"
},
"bar": {
// this is superfluous as permissions are only "granted" and never "revoked" by a child
".write": false
}
}
Note how, because I am the owner, I can also write to foo and to bar, even though bar has tried to revoke my read privilege.
So in your case above, your rules declaration lists read: true which allows full read access to the entire repo. Change that to false and you'll see better results.
Having spent literally days trying the different, various recommended ways to do this, I've landed on what I think is the most simple and promising. Also thanks to the kind gents from this SO question: Get the index ID of an item in Firebase AngularFire
Curent setup
Users can log in with email and social networks, so when they create a record, it saves the userId as a sort of foreign key.
Good so far. But I want to create a rule so twitter2934392 cannot read facebook63203497's records.
Off to the security panel
Match the IDs on the backend
Unfortunately, the docs are inconsistent with the method from is firebase user id unique per provider (facebook, twitter, password) which suggest appending the social network to the ID. The docs expect you to create a different rule for each of the login method's ids. Why anyone using >1 login method would want to do that is beyond me.
(From: https://www.firebase.com/docs/security/rule-expressions/auth.html)
So I'll try to match the concatenated auth.provider with auth.id to the record in userId for the respective registry item.
According to the API, this should be as easy as
In my case using $registry instead of $user of course.
{
"rules": {
".read": true,
".write": true,
"registry": {
"$registry": {
".read": "$registry == auth.id"
}
}
}
}
But that won't work, because (see the first image above), AngularFire sets each record under an index value. In the image above, it's 0. Here's where things get complicated.
Also, I can't test anything in the simulator, as I cannot edit {some: 'json'} To even authenticate. The input box rejects any input.
My best guess is the following.
{
"rules": {
".write": true,
"registry": {
"$registry": {
".read": "data.child('userId').val() == (auth.provider + auth.id)"
}
}
}
}
Which both throws authentication errors and simultaneously grants full read access to all users. I'm losing my mind. What am I supposed to do here?
I don't think you want to store user-specific data under a non-user-specific index. Instead of push()ing to your firebase reference, store the user data behind a meaningful key.
e.g.
auth.createUser(email, password, function(error, user) {
if (!error) {
usersRef.child(user.id).set(stuff);
}
});
Now you can actually fetch user data based on who is authenticated.
The custom Auth in the forge's simulator isn't the greatest but if you hit the tab key after selecting the input, it lets you paste or edit the field. At which point you can add {"provider":"facebook","id":"63203497"} or {"provider":"twitter","id":"2934392"} and hopefully get some useful debug out of it.
Assuming your firebase is something like:
{"registry":{
"0":{
"id":"abbacadaba123",
"index":"0",
"name":"New Device",
"userId":"facebook63203497"},
"1":{
"id":"adaba123",
"index":"1",
"name":"Other Device",
"userId":"twitter2934392"}
}
}
This may work for security rules:
{
"rules": {
"registry":{
"$registryId":{
".read":"data.child('userId').val() === (auth.provider + auth.id)",
".write":"(data.child('userId').val() === (auth.provider + auth.id))||(auth != null && !data.exists())",
".validate": "newData.hasChildren(['id', 'index', 'name', 'userId'])",
"id": {
".validate":"newData.isString()"
},
"index": {
".validate":"newData.isNumber()"
},
"name": {
".validate":"newData.isString() && newData.val().length >= 1"
},
"userId": {
".validate":"newData.val() === (auth.provider + auth.id)"
}
}
}
}
}
Your read rule tested as expected. The facebook user read-tests true on registry 0 and false on 1. The twitter user is false on 0 and true on 1.
I did a couple quick tests on the .write and .validate rules and they seem to work.
Hope this helps at least rule out the firebase security rules portion of things, so you can focus on the AngularFire binding part.