In the last section we started to talk about the structure our data will have inside firebase we're
going to have a top level collection of users.
Each user will have their own bucket of employees.
We then started talking just a little bit about the security of our data.
So it might be surprising to hear this but by default inside of firebase we can even see a little message
right here.
The only default security rules there are is to require that a user is authenticated.
That is the only requirement.
So once a user is authenticate with firebase they can reach out to any data inside of your database.
Absolutely any.
This is by default and we can fix it and we are going to fix it.
But I just want to know that that is the default behavior in here on my console.
I'm on the real time database tab right here.
I clicked the rules tab at the top this rules tab right here changes the security rules of our application.
So by default you can kind of read this vaguely as you know English do not allow or only allow people
to read from our database or write from our database if they are offered.
So if if auth is null do not allow them to read Do not allow them to write any Dade's the application.
So this rules tab right here is where we can set up some number of rules that dictate what data a user
can read and write inside of our database.
So we're going to update this rule set right here with something is going to be a lot more secure for
the application that we are going to make.
We're going to make a change.
This is another one of those locations where all of you know we're gonna throw some code on here and
then figure out what's going on.
So let's just do a little bit of typing and see where it takes us.
First I'm going to delete everything inside of the rules object.
So now I've got just rules and then empty object.
And inside of you are going to add users and I'm going to make sure that I use double quotes just to
make sure that's really clear.
Let's dial up the size here.
So I'm using double quotes around everything.
Then inside of users I'm going to say dollar sign you I.D. and then one more object in here will do
Daut read will the dollar sign your ID equals equals equals Kauth dot you ID and
dot right dollar sign your ID equals equals equals dot you ID.
We can read these rules the seen in my firebase data like in my database there is going to be a collection
of users.
And in that users collection we will have a bunch of keys where each key is a user's ID so you ID right
here is a user's ID.
If a user tries to edit any data inside of this you id property which like it at production time.
In reality this you ID right here is going to be some string of characters that matches up to a very
particular user.
So if a user tries to enter or read or edit any data within this little bucket right here they must
have a user id equal to the ID.
In other words look at the current user's ID if it is equal to the idea of this little bucket right
here.
Then allow them to read or write from this data otherwise denied to them.
So yes this is a little confusing.
Lets glance it a little bit more practical example of something with some actual numbers here.
So I'm back over to our firebase schema diagram.
Again this is what our Jaison is going to look like in practice in the States on diagram We've got two
users.
User 1 2 3 and user 4 5 6.
So the user 1 2 3 4 5 6 are you IDs.
If user 1 2 3 logs in and tries to edit any one of their employees firebase is going to look at the
ID of the currently authenticated user which is user 2:59 and it's going to compare it to this key right
here.
They would be identical you know user 1 2:59 is user 1 2 3.
So they're going to have full read and write access to everything inside this bucket right here.
All the employees.
Any other key is we haven't in here any other data that they're going to have complete access to.
On the other hand if user 2:59 logs in and then tries to edit any data inside of the user four or five
six bucket firebase is going to compare the idea of user 2:59 the currently logged in user to user 4
or 5 6.
They are not equal.
So the user is not going to have read or write access to any of the data inside of this bucket right
here and that's pretty much it.
That's how security works with firebase.
Again this is a very super Just like a super generic schema of data right here.
So if you want to reuse this on your own personal projects its definitely going to take you pretty far
where for any type that where a user has their own little island of data or their own little kind of
bucket of data in here.
So last thing we have to do inside of our firebase consul here I'm going to publish this rule set that
I just created so I can publish it and I see rules published up here that means that now these rules
are in effect and no user can reach out to any other users data.
And you know and go with it.
The last thing I want to say about the Jason data structure if it's still confusing what its going to
look like as soon as we start saving data it's going to pop up and it's interface right here.
So as soon as we start saving data we're going to get our eyes on this thing and say OK yes that is
what this actually looks like and I think at that point in time it's going to start to make a little
bit more sense.
OK.
We've got our data locked down.
Let's continue the next section and start saving the employees that are being created within our application.