Firestore security rules based on map values

Question

I want to store if a user is permitted to read a document in the document itself, based on the user's email address. Multiple users should have access to the same document.

According to the documentation Firestore does not allow querying array members. That'S why I'm storing the users email addresses in a String-Bool Map with the email address as a key.

For the following example I'm not using emails as map keys, because it already doesn't work with basic strings.

The database structure looks like that:

lists
  list_1
    id: String
    name: String
    owner: E-Mail
    type: String
    shared:
      test: true

All security rules are listed here:

service cloud.firestore {
  match /databases/{database}/documents {
    match /lists/{listId=**} {
        allow read: if resource.data.shared.test == true
    }
  }
}

Edit: It also doesn't work if I use match /lists/{listId} instead of match /lists/{listId=**}

How I understand it, this security rules should allow reading access to everyone if the value in the map shared[test] is true.

For completness sake: This is the query I'm using (Kotlin on Android):

collection.whereEqualTo("shared.test", true).get()
        .addOnCompleteListener(activity, { task ->
            if (task.isSuccessful) {
                Log.i("FIRESTORE", "Query was successful")
            } else {
                Log.e("FIRESTORE", "Failed to query existing from Firestore. Error ${task.exception}")
            }
        })

I'm guessing that I cannot access map values from the security rules. So what would be an alternative solution to my problem?

In the Firestore rules reference it's written that maps can be accessed like that resource.data.property == 'property' so, what am I doing wrong?

All the examples I've seen for resource.data don't have the ** wildcard syntax, so maybe resource.data only works if you use match /lists/{listId} instead of match /lists/{listId=**}? Something worth trying. — Scarygami
Hmmm... I'll be honest; this looks like this should be working fine. Can you first double check that you didn't accidentally store your data / edit your rules in the Realtime Database instead of Cloud Firestore? (It happens sometimes) Also, what happens if you don't make this a query and just try to fetch an individual document? — Todd Kerpelman
@ToddKerpelman The data is in Firestore. Not realtime DB. When reading the document directly with db.document("lists/acaa0247-eccd-4ff0-b986-7f8b6187e45f").get() it works. — Marcel Bochtler
this issue is still not fixed (March 2020) despite the claims of the most upvoted comment. So nested properties are not working. Since I can't comment with this account, this is posted as a separate answer. So please restrain from using nested properties in rules. They will work with local tests but not after Deployment. — digitalwert

Todd Kerpelman Todd Kerpelman · Accepted Answer · 2017-10-12T22:07:37

Edit: This issue should be fixed now. If you're still seeing it (and are sure it's a bug with the rules evaluator), let me know in the comments.

I've chatted with some folks here about the problem you're encountering, and it appears to be an issue with the security rules itself. Essentially, the problem seems to be specific to evaluating nested fields in queries, like what you're doing.

So, basically, what you're doing should work fine, and you'll need to wait for an update from the Firestore team to make this query work. I'll try to remember to update this answer when that happens. Sorry 'bout that!

Firestore security rules based on map values

2 Answers