I have collections:

users
files 

(though there could be many different collections beyond files).

Both have an email field, both have an anization field.

I am looking to allow Admin users to read documents in the files collection, belonging to other users, provided they are in the same anization (as specified on the anizationId field of the file itself).

The server side call to Fire base looks like:

const db = getFirestoreInstance();
...
const = await db.collection("files")
  .where("email", "==", email)
  .where("anizationId", "==", anizationId)
  .orderBy("timestamp", "desc")
  .limit(filesLimit)
  .get();


...
let myApp;
if (!myApp){ myApp = initializeApp();}
let fireStoreInstance;

export const getFirestoreInstance = () => {
    if (!firestoreInstance){
       firestoreInstance = getFirestore(myApp);
    }
    return firestoreInstance;
}

The Firebase rules look like:

  match /databases/{database}/documents {
    function isUserAdminInSameOrg(request, resource, database){
        let userObj = get(/databases/$(database)/documents/users/$(request.auth.token.email)).data;
        return userObj.role == 'admin' //this line works
    && userObjanizationId == resource.dataanizationId;  //userObj has the correct value, resource.dataanizationId does not, despite resource.data.email working in the next function
    }

    //this function works
    function doesResourceBelongToUser(resource, request){
        return resource.data.email == request.auth.token.email;
    }
    function Rules(collection, resource, request){
        let collectionsAdminsCanRead = [
        'files'
        ];
        return (collection in collectionsAdminsCanRead && 
                    (doesResourceBelongToUser(resource, request) || isUserAdminInSameOrg(request, resource, database))) 
      || !(collection in collectionsAdminsCanRead );
    }
    match /{collection}/{document} {
      allow read: if request.auth != null && Rules(collection, resource, request);
    }
  }

The goal is to check the authenticated user against the users collection (hence the get), ensure the matching document from the users collection has the field role equaling admin (again verified this works), that it has anizationId equaling the initial collection (in this case files) anizationId.

I was under the impression that resource.data allowed you to access the fields from the document of the collection being queried prior to any execution (in the event it was an create/update/delete) of the query. And in fact this works for checking if the document belongs to the logged in user, checking resource.data.email against request.auth.token.email

I do know that the rules aren't filters, which is why there's where clauses when making the calls. I also know that the rules will reject requests not based on what's actually in the DB, but on all hypothetical scenarios. What am I missing? Is there something in my isUserAdminInSameOrg function that would reject?

I have collections:

users
files 

(though there could be many different collections beyond files).

Both have an email field, both have an anization field.

I am looking to allow Admin users to read documents in the files collection, belonging to other users, provided they are in the same anization (as specified on the anizationId field of the file itself).

The server side call to Fire base looks like:

const db = getFirestoreInstance();
...
const = await db.collection("files")
  .where("email", "==", email)
  .where("anizationId", "==", anizationId)
  .orderBy("timestamp", "desc")
  .limit(filesLimit)
  .get();


...
let myApp;
if (!myApp){ myApp = initializeApp();}
let fireStoreInstance;

export const getFirestoreInstance = () => {
    if (!firestoreInstance){
       firestoreInstance = getFirestore(myApp);
    }
    return firestoreInstance;
}

The Firebase rules look like:

  match /databases/{database}/documents {
    function isUserAdminInSameOrg(request, resource, database){
        let userObj = get(/databases/$(database)/documents/users/$(request.auth.token.email)).data;
        return userObj.role == 'admin' //this line works
    && userObj.anizationId == resource.data.anizationId;  //userObj. has the correct value, resource.data.anizationId does not, despite resource.data.email working in the next function
    }

    //this function works
    function doesResourceBelongToUser(resource, request){
        return resource.data.email == request.auth.token.email;
    }
    function Rules(collection, resource, request){
        let collectionsAdminsCanRead = [
        'files'
        ];
        return (collection in collectionsAdminsCanRead && 
                    (doesResourceBelongToUser(resource, request) || isUserAdminInSameOrg(request, resource, database))) 
      || !(collection in collectionsAdminsCanRead );
    }
    match /{collection}/{document} {
      allow read: if request.auth != null && Rules(collection, resource, request);
    }
  }

The goal is to check the authenticated user against the users collection (hence the get), ensure the matching document from the users collection has the field role equaling admin (again verified this works), that it has anizationId equaling the initial collection (in this case files) anizationId.

I was under the impression that resource.data allowed you to access the fields from the document of the collection being queried prior to any execution (in the event it was an create/update/delete) of the query. And in fact this works for checking if the document belongs to the logged in user, checking resource.data.email against request.auth.token.email

I do know that the rules aren't filters, which is why there's where clauses when making the calls. I also know that the rules will reject requests not based on what's actually in the DB, but on all hypothetical scenarios. What am I missing? Is there something in my isUserAdminInSameOrg function that would reject?

• node.js
• firebase
• google-cloud-firestore
• firebase-security

• We don't know what these rules are going to do because we don't have complete information. For example, we can't see the values of email and anizationId in the query. We also can't see what's in the user account for request.auth.token.email or the contents of the users document for that email. Please edit the question to provide more complete details. We should be able to take your code and data, and run it to observe the same result. I suggest eliminating as many variables as possible, and rely only on discrete, hard-coded values for as much as possible. – Doug Stevenson Commented 2 days ago
• I have updated the question, though I have a feeling it won't be the amount of detail you are looking for. All I want to be able to do is allow a user, after we've checked against where we are internally storing their roles in a separate users collection, to have read access to all of the documents in the files collection, provided they are in the same . I would assume this is a very common pattern... – David Commented 2 days ago
• Yes, you didn't really address any of the concerns from my prior comment. I can't run this to see how it works for myself. The issue isn't simplicity of pattern, the issue is that you haven't provided a complete minimal reproducible example for us to use. – Doug Stevenson Commented 2 days ago
• @David: This code runs server-side, correct? If so, are you using the Admin SDK for Node? If so, your code isn't affected by the security rules. – Frank van Puffelen Commented 2 days ago
• Please provide enough code so others can better understand or reproduce the problem. – Community Bot Commented 2 days ago

1 Answer 1

I was able to trace the root cause of this issue to the anizationId param not coming across the wire to Firebase correctly, which ultimately led to userObj.anizationId == resource.data.anizationId failing as resource.data.anizationId wasn't what it should have been.