Workaround for Firebase's "Rules Are Not Filters" constraint

Question

I’d like a security rule that lets anyone get a list of users and read their names, but only allows logged in users to view their own email.

Here’s an example data structure:

    "User" : {
        "abc123" : {
          "name" : "Bob",
          "email" : "[email protected]"
        }   
    }

A naive approach to a security rule might be to do the following:

"User" : {
    "$user" : {
        "name" : {
            ".read" : true
        },
        "email" : {
            ".read” : "auth.uid === $user"
        }
    }
}

However because there is no read rule at the User level, requests to read the list will be denied. But adding a read rule at the User level will override the email rule, and make every child node readable (see Rules Cascade in Firebase's Security Guide).

The Security guide does point out that Rules Are Not Filters, but doesn’t offer much guidance as to what to do about it.

Should I just split my User entity up into PrivateUser and PublicUser?

Answer 1

To let anyone get a list of users and read their names. AND to allow logged in users to view their own email.

Zac says: first think about access, and then to model objects that are either completely public or completely private.

Type 1:

{"rules":{
  "user_publicly":{"$user:{
    ".read":true,
    "name":{}
  }},
  "user_privately":{"$user:{
    ".read":"auth != null && $user == auth.uid",
    "email":{}
  }}
}}

Type 2:

{"rules":{
  "user":{"$user:{
    "public":{
        ".read":true,
        "name":{}
    },
    "private":{
        ".read":"auth != null && $user == auth.uid",
        "email":{}
    }
  }}
}}