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
Post a Comment