We also don't allow any writing directly to the data nodes but rather have a separate level in the tree where "requests" are written, then a privileged process reads, processes, and writes to the main data nodes, then notifies the client it's done by writing to a "response" node that only the client can read. This helps us make the security rules a little simpler and less error prone to mistakes, but primarily it's so we have a hook to run business processes and validation that doesn't need to be in the client which is unsafe.
I'd recommend using the bolt compiler (https://github.com/firebase/bolt) so that you can write rules using repeatable logic and so that you can actually read complex rules.
How were you thinking of it before? This reads to me how Apache servers have been configured for 20 years.
How does cascading make sense at all if lower-down rules don't supersede higher rules?
But whatever Firebase is doing, it’s the opposite of specificity - it’s closer to “search top down until we find something truthy then stop.” https://firebase.google.com/docs/database/security/
This is simpler and more efficient to implement and run at scale. But imagine if styling worked like that - you could never have colored overlays, or anything we take for granted.
When over-eager marketing speak encourages insecurity, it’s a significant ethical breach.
I do think that if this is such a common behavior the rules DSL could be revised so that fewer people fall down the "pit of success". At the very least do not allow people to define rules that have already been defined by parents. This should be part of Firebase, the fact that theres a startup providing this service is the biggest code smell I can think of telling you there's a problem here.
> Note that .read and .write rules shallower in the database override deeper rules, so read access to /foo/bar/baz would still be granted in this example even if a rule at the path /foo/bar/baz evaluated to false.
https://firebase.google.com/docs/database/security/
This seems unreasonable at first glance. Does anyone know the rationale for it?
Then I spent months where Whenever I needed to solve a use case I’d spend more time thinking about how to structure my data, how to secure it. I’d spend a lot less time actually building features and more time twisting myself into knots figuring out how to make it work with security rules. It feels backwards to me to have security dictacte the structure of my data rather than the business needs.
I switched to Azure functions front ending my data, which resides in Cosmos DB. Now I can structure my data in a way that suits the business need. Security is incomparably easier now and more flexible.
