We have a firebase structure as an attached image.
My current rules are
"Games":{
".read":"query.orderByChild == 'email' ",
"$gid":{
".read":true,
".write":true
},
".write":false,
}
This helps to disable access to parent but when there is blank email id is passed it was fetching the whole database so is it possible to check the length of email using rules?
It is hard for me to validate this answer blindly (so take it with a grain of salt), but I hope this will give you a directional help.
So the "download" in your case means the ability to read db.ref('/Games') should not be available, but a user (or certain users group?) should be able to read db.ref('Games/$gameId').
According to this article: https://firebase.google.com/docs/database/security/securing-data#rules_are_not_filters
you can not achieve this with security rules restricting ".read": false at "/Games" level, cause this will prevent reads for any of the gameIds, since the security rule will cascade.
what you can do is to try using queries as way to "filter" as described in the article:
"Games":{
".read":"query.orderByChild == 'email' ",
"$gid":{
".read": "query.orderBy("email") && query.equalTo === $gid",
".write":true
},
".write":false,
}
So your DB query should be something like:
gamesRef = database.ref('Games').orderByChild('gameId').equalTo(20204315123456)
The above assumes that the gameId is also a property of each $gameId item inside Games list. The query above will check Games list for children whose property is "gameId" and that are equal to the value provided by the client (same as the key).
Hope that will help you.
Related
I have two collections - tenancies and users.
A tenancy doc has a field called "landlordID" and is of type REFERENCE (not String).
Now in my Firestore Security Rules I want to allow a tenancy to be updated ONLY IF the landlordID field of that tenancy matches with the uid of the user making the request, namely request.auth.uid.
Read it as " allow a tenancy document to be updated if the user making the user is authenticated, hence request.auth.uid != null, and the landlordID field's ID should be equal to that of the request.auth.uid.
Hence the code should me something like this:
service cloud.firestore {
match /databases/{database}/documents {
match /tenancies/{tenancyID}{
allow update: if request.auth.uid != null &&
request.auth.uid == get(resource.data.landlordID).id
}
}
I have also tried get(/databases/$(database)/documents/users/$(resource.data.landlordID)).data.id
Supporting screenshot of my database
This should be very simple but get() simply does not work. Firebase Docs, scroll to "Access other documents" was not helpful at all for my situation and I am not sure how to get it working.
It would be a shame if references can't be used like this as they are just like any other field of a document.
Here is a function I made that works for me. I guess you have a user collection with users having the same id as their auth.uid
function isUserRef(field) {
return field in resource.data
&& resource.data[field] == /databases/$(database)/documents/users/$(request.auth.uid)
}
Adjusting to your use case you'd call the function so: isUserRef('landlordID') although the ID at the end of it is a bit misleading as this field is in fact a reference.
I see a couple of issues here. A first problem is that the get() function expects a fully specified ducument path, something like:
get(/databases/$(database)/documents/users/$(resource.data.landlordID)).data.id
A second problem is that you are trying to use the reference type in your rules, I do not think that is possible unfortunately.
The reference type in Firestore is not very helpfull (yet), I think you should store the landlordID as a string, then you can simply do something like:
service cloud.firestore {
match /databases/{database}/documents {
match /tenancies/{tenancyID}{
allow update: if request.auth.uid != resource.data.landlordID;
}
}
I had the same issue I needed an answer for. See this Google-thread with the answer from someone from google. To quote it:
You can get an id out of a path using the "index" operator:
some_document_ref should look like /databases/(default)/documents/foo/bar
which has 5 segments: ["databases", "(default)", ...]
some_document_ref[4] should be "bar"
allow create: if request.resource.data.some_document_ref[4] == "bar";
You can also use the normal get and exists functions on them.
A few difficult aspects of this that you may run into:
There's no way to retrieve the number of segments in a path at the moment (we're adding this soon), so you'll need to know some information about the reference ahead of time
There's not great support for writing references using the simulator in the Firebase Console. I used the Firestore emulator to test out this behavior (gist1, gist2)
might be too late, but I was able to piece together (despite a lack of docs) that a document reference is just a path, and complete path can be created with
/databases/$(database)/documents/users/$(request.auth.uid)
Then I have an array/list in firestore of references, called reads that I can grab with:
get(/databases/$(database)/documents/users/$(userId)/userinfo/granted_users).data.reads
Leaving me able to create a bool, and a rule with:
/databases/$(database)/documents/users/$(request.auth.uid) in get(/databases/$(database)/documents/users/$(userId)/userinfo/granted_users).data.reads
obviously your data structure will vary, but knowing the ref is a path is the important part here.
I had to experiment a little to get this working. Here the function that worked for me
function isUserRef(database, userId) {
return 'user' in resource.data
&& resource.data.user == /databases/$(database)/documents/users/$(userId);
}
And I call it like:
match /answers/{answer} {
allow read:
if isUserRef(database, request.auth.uid);
}
As mentioned by some other answers, a reference has a path property that is just a string that will look something like users/randomuserid123. You can split that into an array and match it against the user making the update request.
...
match /tenancies/{tenancyID}{
allow update: if request.auth.uid != null &&
resource.data.landlordID.path.split('/') == ['users', request.auth.uid]
}
...
Also had a trouble handling this problem, but in my case I needed to allow the user to add a message into a chat only if they're the owner of that chat room. There are 2 "tables" - chats and chat_messages, and chat_messages relate to a specific chat through chatId field. chats objects have ownerId field.
The rule I've used goes like this:
// Allow adding messages into a chat if the user is an owner of the chat room
match /chat_messages/{itemId} {
function isOwner() {
return get(/databases/$(database)/documents/chats/$(request.resource.data.chatId)).data.ownerId == request.auth.uid;
}
allow read: if true;
allow create: if isOwner();
}
I'm trying to implement a Firebase rules read restriction in a data model that has a few nested dynamic child nodes.
I have the following data model:
/groupMessages/<groupId>/<messageId>/
{
"senderId": "<senderId>",
"recipientId": "<recipientId>",
"body": "..."
}
groupId, messageId, senderId and recipientId are dynamic ids. I would like to attach a listener to the /groudId node to listen to new messages. At the same time I only want users to read the message where the senderId or recipientId matches a corresponding auth.token value.
Due to Firebase cascading rules, if I allow the read at the groupId level without restrictions, I can't deny them on the message level.
{
"rules": {
"groupMessages"
"$groupId": {
".read": "auth != null"
}
}
}
}
I also haven't found a way to restrict the read rule on the groupId level to check for sender/recipientId of a message.
Any suggestions greatly appreciated.
As you've found, security rules cannot be used to filter data. But they can be used to restrict what queries can be performed on the data.
For example, you can query for all messages where the current user is the sender with:
var query = ref.child("groupMessages").child(groupId).orderByChild("senderId").equalTo(uid);
And you can secure access to the group's messages to only allow this query with:
{
"rules": {
"groupMessages": {
"$groupId": {
".read": "auth.uid != null &&
query.orderByChild == 'senderId' &&
query.equalTo == auth.uid"
}
}
}
}
The query and rules now exactly match, so the security rules will allow the query, while they'd reject a broader read operation. For more on this, see query based rules in the Firebase documentation
You'll note that this only works for a single field. Firebase Database queries can only filter on a single field. While there are workarounds by combining multiple values into a single property, I don't think those apply to your scenario, since they only work for AND queries, where you seem to want an OR.
You also seem to want to query on /groupMessages instead of on messages for a specific group. That also isn't possible: Firebase Database orders/filters on a property that is at a fixed path under each child of the node where you run the query. You cannot query across two dynamic levels, as you seem to be trying. For more on this see: Firebase Query Double Nested and Firebase query if child of child contains a value.
The common solution for your problem is to create a list of IDs for each user, which contains just the IDs of all messages (and/or the groups) they have access to.
userGroups: {
uid1: {
groupId1: true,
groupId2: true
},
uid2: {
groupId2: true,
groupId3: true
}
}
With this additional data structure (which you can much more easily secure), each user can simply read the groups they have access to, and your code then reads/queries the messages in each group. If necessary you can add a similar structure for the messages themselves too.
Finally: this type of recursive loading is not nearly as inefficient as many developers initially think, since Firebase pipelines the requests over an existing connection.
I have sign up system where I want only users to sign up if they have a valid secret key which I shall provide to users who want to register. If key is in db, then proceed to sign up. Thus I have generated random non repeated 8 chars and stored them in the real time database in the following structure:
Secrets:
"x5f1n9v0":
"Status" : 1
"C8vT2xxY":
"Status" : 1
And so on
..
{
"rules": {
"secrets":{
"$secret": {
".read": true,
".write": false
}
}
}
}
First question regarding the aboves rules:-
In this case no one can add a new secret key ?
Also the read will only be valid if someone has a valid key from my list ? Nobody can read the whole list ? Any bugs in this ?
Now suppose another set of rules where I want to write to the child of each key iff the user knows the valid id.
If I change the rule for write to true, will this work and no bugs to hack it ?
"rules": {
"secrets":{
"$secret": {
".read": true,
".write": true
}
}
}
}
Thanks
In this case no one can add a new secret key?
With those first rules, only someone with administrative access can add keys.
Also the read will only be valid if someone has a valid key from my list? Nobody can read the whole list?
There is indeed no way to read the entire list with your first set of rules. Someone can only read a secret if they know its key.
With your second set of rules:
"secrets":{
"$secret": {
".read": true,
".write": true
}
}
Now anyone can write any secret. That is probably not what you want. If you want to only allow them to change the data that already exists under an existing key, you'll want to check if there is any data already:
"secrets":{
"$secret": {
".read": true,
".write": "data.exists()"
}
}
If you want them to not be able to change-but-not-delete the existing data, that would be data.exists() && newData.exists(). If you have additional requirements about the data formats users can write, you'll want to add those to a corresponding .validate rule.
Your last set of rules is both invalid and meaningless. It's invalid because $secrets is not defined. But even if it was defined $secrets === $secrets will always be true.
I found a neat little example for permission based chat rooms using firebase security api here
Notice the "chat": {
// the list of chats may not be listed (no .read permissions here)
I actually need to list the chats a user belongs to when I load their inbox, however I can't seem to get the .read rule correctly.
Ive tried using the following rule which makes total sense but doesn't work:
"convos": {
".read" : "auth != null && data.child('users').hasChild(auth.id)",
I suspect the problem is that there is still a level between convo and users.. aka would make more sense to do:
"convos": {
".read" : "auth != null && data.child($key + '/users').hasChild(auth.id)",
$key : { ... }
But that's not allowed is complains about $key not existing yet.
How can I allow a user to pull all the convos they belongs to using this setup?
You can't use security rules to filter data. Generally, your data structure will be fairly dependent on your specific use case--most directly on how the data will be read back.
A general solution is to list the chats your user belongs to separate from the bulk chat data, i.e. to heavily denormalize, and access the chats individually.
/messages/$chat_id/... (messages chronologically ordered using push() ids)
/chats/$chat_id/... (meta data)
/my_chats/$user_id/$chat_id/true (the value here is probably not important)
Now to access all of my chats, I could do something like the following:
var fb = new Firebase(URL);
fb.child('my_chats/'+myUserId).on('child_added', function(snap) {
var chatID = snap.name());
loadChat(chatID);
});
function loadChat(chatID) {
fb.child('messages/'+chatID).on('child_added', function(snap) {
console.log('new message', chatID, snap.val());
});
}
You would still want security rules to validate the structure of chat messages, and access to a users' chat list, et al. But the functionality of filtering would be done with an index like this, or by another creative data structure.
I'm not completely sure how you're structuring your Firebase, but this might work:
"convos": {
$key : {
".read" : "auth != null && data.child('users').hasChild(auth.id)",
...
}
I'm having an issue setting my Security rules properly, specifically reading the post data.
The data hierarchy goes:
posts : {
0 : {
title: "Post One",
userId: 6
}
},
users : {
6 : {
name: "My Name"
}
}
And my rules are:
{
"rules": {
"posts" : {
"$post": {
".read":"data.child('userId').val() == auth.id",
".write":"newData.child('userId').val() == auth.id"
}
},
"users":{
"$user": {
".read":"auth.id == $user",
".write":"auth.id == $user"
}
}
}
}
I know that the "auth.id" is 6, because it's pulling the rules correctly for my user info. If I change the rules to pull the number statically, it works:
"$post": {
".read":"data.child('userId').val() == 6",
".write":"newData.child('userId').val() == auth.id"
}
but using auth.id does not. Is there something I'm missing?
One thing to keep in mind is that security rules are type-safe. In particular, In the rules, "6" != 6 (since one is a string and one is a number). So perhaps your auth.id is "6" (as a string), but your userId is 6 as a number?
If that's the case, one potential fix would be changing your rule expression to something like:
data.child('userId').val() + '' == auth.id
which will force userId to be a string. Alternatively, you could change your data to make sure userId is always stored as a string.
You haven't included the code you're using to look up this data--probably where the error is--or the error you are receiving; those would help quite a bit.
Your rules should work fine, assuming you are attempting to read a single post at a time, and assuming your authentication is set up correctly.
A quick guess would be that you're trying to read the entire "posts" path, and using security rules to filter your posts. But security rules are essentially atomic. If you try to read "posts", and one of the posts has a rule that prevents read, the entire operation is going to fail.
Instead, you need to segment the posts into paths where all the data can be read by the authenticated user, then you can apply security rules accordingly.
One thing that will help immensely is to test your security rules by going into your Forge and using the "simulator". You can log in as any user, then try a read/write, and see exactly which security rules is failing and why.