Common Mistakes in Firebase Security Rules

Re:Common Mistakes in Firebase Security Rules by rhizome on Tuesday April 10, 2018 @11:36AM (#16802122)

This was a different way of thinking about security rules for us. But basically you have to make everything not readable and not writable at the root and then open up access farther down. And the way you need to structure your data will be affected. You might have a "user" level in the tree but you make a child level "private" readable by the actual user and no one else, like /users/$userId/private. Then you might have a /users/$userId/public that anyone can read, etc.

How were you thinking of it before? This reads to me how Apache servers have been configured for 20 years.

[ Parent | on HN ]

Re:Common Mistakes in Firebase Security Rules by realpeopleio on Tuesday April 10, 2018 @12:11PM (#16802437)

Like some other commenters here. Like the rules would cascade down similar to css. You might think that a read rule on a parent node would apply to a child unless that child overrode the that rule. But it doesn't. So you keep having to read the rules up the hierarchy to see who could ever read the node.

[ Parent | on HN ]

Re:Common Mistakes in Firebase Security Rules by rhizome on Wednesday April 11, 2018 @05:19PM (#16815791)

Sounds like the functionality we see configured in e.g. .htaccess files.

[ Parent | on HN ]