Everyone welcome back Johnny be here with this laptop.
And in this lesson we are going to work on our security rules and we're going to take a look at some
more advanced things that you can do with them and really fine tune in lock down some of our paths.
All right.
So this is where we left off in the last video we are able to now edit comments and delete them so we
can edit and police.
That's pretty cool.
But just take a look at our security rules because there's some things that we should change up here.
So I want to jump into our firebase dashboard here in our database tab here and we're going to take
a look at our rules.
And in the last course I want to fix something real quick.
I put off that I.D..
This should be off you I.D..
All right I want to publish that and just get that out of the way and let's talk a little bit about
what we want to work on here what we're going to fine tune.
So right now when we are in our app we are saying here that anyone as long as they are logged in they
can modify and create and delete any document from the thoughts collection and down.
What that means is that if someone had the document path to any of your thoughts or comments they could
potentially update them or delete them or you know whatever it is that they wanted to do.
So let's go ahead and we're going to we're going to try and lock this down a little bit tighter.
So first thing we're going to do is we are going to get rid of this recursive wildcard so that now this
these rules here only apply to the documents in the thoughts collection.
And what we're going to do is we're going to leave the thoughts collection alone for now because we
haven't done anything there yet.
We've been working primarily in the comments collection being able to delete and edit them.
So let's go and create a new match here with the same match.
And remember that if you continue a match from inside of a match you can just continue on the path.
So we've gone from thoughts and thoughts.
So this is going to continue at the comments and wildcard comment.
OK.
And now the rules that we write here will only apply to the common collection and the documents inside
of that collection.
So what do we want to have happen.
I don't think that anyone that is logged in can read the comments meaning that we can still display
them.
So we're going to do that first one to say allow or read if the request thought often is not equal to
no.
So if someone is logged in then they can read the comments.
Now what you've seen up till now is right and create.
So right is the catch all inside of that we have create update and delete.
So we're going to handle each of those cases separately.
OK.
So anyone should be able to create a comment right.
As long as they're logged in.
So again we're going to say allow create if the request thought off does not equal the whole.
And I could have put this right here on the same line with the read but I wanted to just show you how
you can break these out into their individual read and write components.
And now Next up we have we're going to do we can do that delete.
OK.
So who can delete a document a comment in this case.
Well we wanted to make it so that the only person that can delete a comment is the person that actually
made the comment.
So to do that we are going to compare the request ID and compare that with the the resources document
data where we have stored the user id and that's why we did that whole process in the beginning of the
Course.
To add to the user id both the thought and comment documents.
OK.
So how we do that is we say allow them to if the request off dot UAD is equal to.
And then we have the resource that data.
User ID.
OK let's talk about this real quick.
So the request has two pieces of information the off.
And then a resource.
OK.
And so you can kind of think of it as coming and receiving so the request is coming from our app and
it's going to the fire store database resource here.
This is what's already in the database.
So what we're doing is we are comparing the the authorization information in the requests that's coming
to the fire store and we're looking that and worse we're finding the idea the unique identifier of the
person making the request and we're comparing that with what is already in the fire store database in
this case a comment document.
And we're looking at the data inside of it.
And we're finding the user id field and we're comparing that value to the ID that is coming from the
request and only if those are equivalent if those are equal.
Will we allow that person to delete it.
All right so let's go ahead and well you know what let's go ahead and see what it looks like when you
when we don't allow this.
All right.
I'm going to comment this out actually.
We're going to publish this and we're going to try and do it delete and then I want you to be able to
see the error of that X code or that firestorm throws us up letting us know that hey something's not
quite right with your security rules.
I want to jump back into ex-coach here and actually we just need our simulator.
And I think it's been long enough for that rule to propagate.
So I'm going to go ahead and delete this comment right here.
If you if you are logged in you can create a comment and delete it.
Some would say delete comment and let's see here.
Yep sure enough it did not delete.
First off but if we come into here in X code you'll see here we have transaction failed.
And it says let's see here missing or insufficient permissions.
All right so that is telling you that you're trying to do something but is because of your security
rules that you are not able to.
You don't have the correct permissions set.
All right so that is what happens when when you don't have the right the correct the security rules
set.
Or if someone is trying to do something that they shouldn't be doing.
All right so now if we publish this and wait just a couple of seconds here we'll we'll try that again
and see if we can delete them.
All right.
So I've waited a few seconds so it's good to try and delete this now.
And there it goes.
All right so now we know that our delete is working.
So how about that update.
So we tried to update something here has created a new comment real quick and I'm going to try to edit
it.
And I'm just going to put something different and say update and that is not going to work and X code
should give us a yet unable to update comment missing or insufficient permissions.
All right so now we need to add the rules for updating.
When you say allow update and the first part is going to be the same as the above we're going to say
if request that your ID is equal to the resource that data user ID.
So if the person that created the comment is the same person that is trying to edit the comment then
they can go ahead.
But and this is just to kind of show you some of the stuff that you can do what you can do is you can
also add other conditionals.
So we're going to see if the if it's the person that owns the comment but also we want to make sure
that they're not trying to change other things like the user name or if you wanted to make sure that
the time stamp stays the same whatever it is I'm going to make sure that the username stays the same.
So we can do that by saying request that resource.
So I had kind of talked a little bit about how requests have the authorization information as well as
the resource information that is being sent up to five store.
So this resource information this contains everything.
And let's see here.
This is in comments the sea I believe.
So for instance and when we created common we sent up the common text time stamp user name and user
ID.
So we have access to that here as well.
So we're going to say data that user name is equal to the resource that is currently in fire store data
data user name.
So if those two aren't the same if the if the user name information doesn't match then then they won't
be able to update.
All right so I think that's about it.
I'm going to publish this and we'll wait a few seconds and we will try this again.
Oh I see a typo here that should be the source.
And there we go and publish that and we'll give that another try.
I'm back in the simulator going to try editing this comment here.
It is the update.
And there it's working.
All right so very nice.
I'm going to try and delete this make sure that's still working as well.
So leave a comment on that.
Looking good.
We can create Common's it so I think we got our comments collection and documents locked down and fine
tuned in a pretty good way.
All right.
So just to recap here we allow read and create if the user is logged in we allow deleting if the user
id in the request matches the resources user ID and we allow updating if the requestors ID matches the
resources user ID as well as saying that the incoming user name matches the existing resources user
name as well.
So thats just a little peek into some of the more advanced Firestar security rules that we can that
we can do and we're going to be doing a little bit more advanced stuff here a little bit later when
we when we look at the thoughts comments as well.
All right.
So we're looking forward to that and we'll see you in the next one.