Firebase allows you to control database authorization through declarative rules. Rules can validate user access and input data. The rules simulator helps test rules. Rules run top-down and cannot be used as filters, so the data structure may need changes to implement authorization. Firebase provides an authentication system as well as hosting, storage, functions and other features in its application framework.
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Firebase Authorization
1. Hey yo, can I see your
firebase stuff, AUTH
course you can
An emotionally fraught memoir of database authorization
2. Firebase - Apps not Ops
Not just a database it’s an entire application framework and offers….
Hosting
Authentication (leveraging many providers or custom email/password)
File Storage
Analytics
Cloud Functions – Server Side Execution.
Cloud Messaging – By ID, Group or subscribed to a topic
A strong feeling of belonging
3. Database Authorization
This isn’t about who you are but what it is you can do
Often it’s managed at a user/role level in terms of SQL and can be quite
heavyweight
Other times with NoSQL DB it can be just lacking altogether
Firebase is lighter in all regards. It’s essentially a JSON document with some
lovely wrapping tooling around it. You don’t need to install a heavy JDBC
client or management studio to use it. Restful API or through management
console
So it should be no surprise that setting up the Authorization is pretty lovely as
well.
The rules we are about to see for controlling access can also put input
validation on fields and indexes for querying
4. Database Authorization
Example DB Rules
{"rules": {
"foo": {
".read": true,
".write": false
} }}
Or this which allows write operations as long as the value of the /allow_writes/ node is true, there is a
sibling node called ‘Admins’, and there is a child named foo in the newly written data:
"rules": {
"ruleDemo" : {
".read": "auth != null",
".write": "root.child('allow_writes').val() === true &&
newData.child('foo').exists() && data.parent().child('Admins').exists()"
}
6. Rules Simulator
Sandbox for testing your rules out. Try different operations and different data
Tired of being you? Be someone different
Spoof authentication to show what happens if you are a certain user
8. Syntax – Helper Methods
References ala DOM operations (root/child)
Variables Auth Object including UserID. Below compares it to a variable.
"users": {
"$uid": {
".write": "$uid === auth.uid"
}
Existing Data vs New Data
// we can write as long as old data or new data does not exist
// in other words, if this is a delete or a create, but not an update
".write": "!data.exists() || !newData.exists()"
9. Rules as Filters
Let’s say our successful website selling erotic cakes and other less erotic baked goods is doing
well. We would like for users to be able to only view products which are suitable for work
We could just write a rule that let’s us do that and then query Products right… NO! Cries and
runs away
.read and .write rules work from top-down, with shallower rules overriding deeper rules. If
a rule grants read or write permissions at a particular path, then it also grants access to all
child nodes under it.
Deny by Default so unless we have an explicit rule on /Products we can’t view it even if we
can view 100% of it’s children
10. Rules not as Filters then fine
RULES ARE NOT FILTERS says google in a kind of passive aggressive way
https://firebase.google.com/docs/database/security/securing-
data#rules_are_not_filters
You need to restructure your data and reprioritise your life
All Public or All Private
11. Summary
Firebase allows you to put fine grained control on your data in a nice
declarative way
You can use helper methods and functions to do some neat things
You can use the simulator to test your rules after you’ve set them
Do not use Rules as Filters. It doesn’t work like that but there’s ways around
it
Firebase got me like
Rules are applied in an atomic manner. That means that a read or write operation is failed immediately if there isn't a rule at that location or at a parent location that grants access. Even if every affected child path is accessible, reading at the parent location will fail completely. Consider this structure:
