14

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?

Marcel Bochtler
  • 1,291
  • 1
  • 14
  • 23
  • 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 Oct 10 '17 at 19:58
  • No, unfortunately this is also not working – Marcel Bochtler Oct 10 '17 at 20:06
  • 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 Oct 10 '17 at 21:34
  • @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 Oct 11 '17 at 06:24
  • 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 Mar 16 '20 at 16:01

2 Answers2

12

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!

Todd Kerpelman
  • 16,875
  • 4
  • 42
  • 40
  • Is there any update on this or place to check ourselves? I am also blocked by this issue and with no good workaround (short of restructuring the data) we're left hanging – Daniel Bickler Oct 24 '17 at 18:16
  • 2
    No update yet, but I know the team is actively working on it. – Todd Kerpelman Oct 26 '17 at 00:18
  • 1
    @ToddKerpelman is looks like from your edit this is working. Should it work with email addresses? There's a comment here https://stackoverflow.com/questions/46631421/firestore-database-rules-and-structure-for-sharing-documents-between-users that says it won't. I've created a new issue for this case https://stackoverflow.com/questions/49265907/firestore-rules-and-query-for-document-map-with-email-keys-to-share-data-with-us – ralphinator80 Mar 13 '18 at 21:16
  • Hello, having a similiar problem here which is very confusing. https://stackoverflow.com/questions/50929366/cloud-firestore-reactjs-error-missing-or-insufficient-permissions Thanks very much :) – Michael Jun 20 '18 at 14:39
1

Whenever you have (optional) nested properties you should make sure the property exists before continuing to check its' value eg.

allow read: if role in request.auth.token && request.auth.token[role] == true

in your case: 

allow read: if test in resource.data.shared && resource.data.shared.test == true

, I was struggling a long time with roles until I realized that on non-admin users the admin field is undefined and firestore rules just crashes and doesn't continue checking other possible matches.

For a user without token.admin, this will always crash no matter if you have other matches that are true eg:

function userHasRole(role) {
  return isSignedIn() && request.auth.token[role] == true
}
Gerardlamo
  • 1,505
  • 15
  • 21