Welcome back class everyone Johnny be here with slopes dot com and in this lesson we are going to finally
add some security rules.
So if you recall from the previous course when we created our project if you look in our rules we have
ourselves a little warning here and says anyone with your database reference will be able to read or
write to your database.
So you just get up and running.
We accepted this but now that we are you know kind of approaching completion of our project we want
to make sure that we lock it down and make it so the only people that we want to be able to read and
write can get.
So just to start out with let's go ahead and take a look at the current rules as are and kind of get
a feel for what these rules do.
So it's written a little bit.
Kind of like javascript and ends at the top level.
We have this service cloud that firestorm don't need to worry about that next line is and match and
databases database inside the curly brace and then slashed documents.
And so this is the top level database path in every file or database.
You'll have this we don't actually see this if we take a look in our database.
We don't see that but it is if it existed it would be like over here.
So you would have that path.
And then our thoughts collection and then our documents so on.
OK.
So you also don't need to worry about this too much.
The next to the line is what makes it so that anyone can read or write.
We have a match here.
And what this match does is the way that the security rules work is by setting rules on specific collections
or documents.
And this match is saying what that specific collection or document is.
And so what we have here is it's basically saying that any document.
That's what the curly braces and the equal with the asterisks mean is that any document can allow reading
and writing.
OK so another we kind of understand how it is right now when it's allowing anyone to read and write.
Let's go ahead and start to restrict it a little bit.
So just thinking about our app I think that it makes sense for anyone who has logged in who is authenticated
to be able to read and write to our thoughts collection as well as to our comments.
Right.
So let's go ahead and figure out how to write that out.
So I'm just going to delete this and I'm going to say match slash thoughts.
OK.
So that's saying.
So that's getting our thoughts collection and then I'm going to use the curly brace and I'm going to
say I thought.
And then curly brace.
So what this is doing is saying any request that is inside of the thoughts collection and any of the
documents and let's write our rule.
So we're going to say allow read and write and then we do a colon and then we have our condition OK.
So we're in allow read and write IF And so what is our condition.
We want to restrict it to those that are often dictated lugged in.
And so with each request that is received to the database we have access to that request and we can
say request dot and then we have two properties that we can look at we can look at the resource of the
document that is being sent up or the authentications who can say request that off is not equal to.
No.
OK.
So it just goes through the skin we're saying if it matches thoughts collection and any of the thoughts
then we are going to allow read and write if the request authorization is not equal to null.
So if this is a valid authentication then go ahead and allow read and write to any of the thought documents
in the thoughts collection.
OK.
And you can specify individual documents.
So for instance if we checked in data and we grab one of these IDs here and we went to our rules we
could no effort to save them.
Whenever you change is you have to publish it.
And so I'm just going to put that back because it was real quick.
So this was a match slash thoughts slash thought and then allow read right.
If the request that off does not equal no.
And then to say what we have to publish.
And you'll see here that the published changes can take up to 10 minutes to propagate.
So I'm going to try not to press that too often in my experience it's more like one or two minutes.
To be able to see those changes in your actual app.
But anyways so we were saying that if we wanted to we could specify rules for individual documents as
well.
So here instead of curly brace thought I'm going to paste that ID.
So if we did this then we would be setting rules for just that one single document.
But that's not what we want to do.
We want to set it for all of the documents inside of the thoughts collection and this word thought this
is just a placeholder could be anything it could be I term it could be object you know.
But since we're you know kind of looking in the thoughts collection thought makes sense.
So inside of our collection we can read and write to any thought if we are authenticated and logged
in.
So now how about the comments collection.
Well we can do that too.
We can say match slash fots slash any of the thoughts and then we go a level deeper than we go to comments
and then slash and then curly brace to do you know the wildcard any comment and then we say the same
thing allow read and write if the request got off does not equal.
Now another thing that we could do instead of having this having instead of writing out the entire path
here what we could do.
I'm going to comment this and here under our match thought thought we could write another one we could
stay here and match.
And then this would continue from right here.
So then we could say comments and then cruelly braes comment and then I'll read and write if requested
off does not equal no.
And so this is equivalent to what we had before.
Instead this is what this is doing is it's just sort of continuing on from right here and these rules
will only apply to this and these rules will only apply to this game.
And it's important to know that the rules by default they don't cascade.
So if we had just done this allowing read and write to the thoughts documents then that doesn't automatically
mean that anyone who's offline could comment or it could read and write the comments OK.
There is a way to do that and that's using that wild card that we saw earlier which was the equal and
the asterisks.
So if we did that then we are saying any of the documents in the thoughts collection and any of their
sub collections can be read read and written to just if you are law often.
So I'm actually going to end with it like this because that is the behavior that we want we want anyone
who is off then to be able to read and write to any of the documents in the collection or any of their
sub collections.
OK.
And all actually go ahead and delete this as well.
And so another thing that we could think about is the users collection.
We haven't done too much with it in this course.
We created it.
So we're going to publish this so that we can take a look at our data we have here our users collection.
Now if you're a user you don't want other people to be able to write to your data or maybe even read
it.
And so what I'm thinking is we only make it read and write if the person that is requesting the request
is the same person that is in him.
So to do that we jump into our rules.
And hear what we're going to do is we're going to say match and we're going to take a look in the users
collection and we're going to say user ID.
And we're going to say allow read and write if the request dropped off dot ID.
So now we're taking a look at the at the request that's coming in.
And if the person that is off in is equal to the user ID then they can read and write right to it.
All right.
So it's kind of a little bit difficult to wrap your head around at first but there are some there's
some great documentation.
If you just search fire store security rules then right here you can read through and there's a whole
lot of information here.
Basically I've just shown you kind of the the most common rules that you'll use which is to allow reading
and write to your collections based on whether or not you are often and whether or not you are the specific
user that is making the request.
As we have it right now though we're going to run into a problem because right now we're only allowing
reading right if the request got off that ID is equal to the user ID.
Well what about the case where we're trying to create a new user.
And this isn't going to work.
So what we need to do is we need to make it so that anyone in the app can create a new user.
And so we can do that by saying allow create and then anyone can create a new user.
I want to publish that and then we'll jump back into X code and see how that's working.
Right so I'm going to run this and we'll see if it's been enough time it might not.
If it hasn't been I want to show you what it looks like.
All right so looks like we can read our thoughts collection Let's go ahead and try and add one real
quick.
When I post this it looks like we can post so we can write to Arafat's collection.
Let's go and check out a comment.
And so we can see our comments so we can read to it.
And let's go ahead and write to it.
Writing
and sure enough we can write to it as well.
All right.
So that pretty much wraps it up for this target topic course in this course.
We have covered a lot we have learned about how to authenticate users using the firebase authentication
SDK specifically using email and password.
Then we added a new feature for being able to write comments on posts and there we learned about transactions
and being able to do multiple reads and writes out one time and then finally we finished up learning
about security rules and how to lock down specific paths and collections and or documents based on whether
or not you're off in or whether you are a specific user.
And there's a lot more that you can do you can get pretty complicated with your security rules.
So look into that some more do some research and I hope you guys enjoyed this course and I'll see you
around.