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


i’d security rule lets list of users , read names, allows logged in users view own email.

here’s example data structure:

    "user" : {         "abc123" : {           "name" : "bob",           "email" : "bob@hotmail.com"         }        } 

a naive approach security rule might following:

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

however because there no read rule @ user level, requests read list denied. adding read rule @ user level override email rule, , make every child node readable (see rules cascade in firebase's security guide).

the security guide point out rules not filters, doesn’t offer guidance it.

should split user entity privateuser , publicuser?

to let list of users , read names. , allow logged in users view own email.

zac says: first think access, , model objects either public or 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":{}     }   }} }} 

Comments

Popular posts from this blog

sql - VB.NET Operand type clash: date is incompatible with int error -

SVG stroke-linecap doesn't work for circles in Firefox? -

python - TypeError: Scalar value for argument 'color' is not numeric in openCV -