- [Instructor] So depending on how old you are,
I'm going to sound like either Steve Jobs or Columbo,
and that's because I've got one more thing.
And what I wanted to talk about was
the database security rules.
Now I'm just going to touch on them
because this is a pretty complicated topic,
and you should really read the documentations,
but I wanted to sort of give you enough
to be a little bit dangerous.
So what I want to do is talk about
what you get when you first start,
which are these very permissive rules,
and how to lock them down just a little bit.
And what you can see here is that Firebase
allows you to get into the database
via the different paths,
and these don't have anything to do with your routes.
They have to do with the structure of your data,
so if we take a look at our data,
we have a sort of homepage right here
when you click on this button,
and then we have a Users collection,
a series of one or more documents,
and in the documents, we also have
a Meetings sub-collection,
and then we have some other documents,
and some of these documents will have
an additional Attendee section
depending on what you've done as you played around
with the project.
And then you have also a number of sub documents
with, perhaps, some information like this.
So this right here is the path that really matters,
and in the rules, you can lock down access
to each of the paths, and how that access is locked down.
So to begin with, this match statement right here
is pretty much matching the entire document.
Actually, this top one is actually the route,
or the homepage, of your database.
And then you can write additional match statements here
in order to lock down sub-paths
in your database.
So what we can do here is specify a little more clearly
how we want to lock things down
with additional match statements.
So what I can say is I want to go ahead
how users have access to this user section,
and I can use an identifier here that acts
sort of like a variable, and then say that
if somebody goes into my Users database
and finds a document in there,
and then if they try to do something
in the Meetings section, what we can do is
go ahead and use that wildcard to say any document,
and we'll use the double stars just like before,
will be controlled with the following rules.
So in here we can use words like allow,
and we can put things in here like read
and write and get and other HTTP verbs.
So you can say allow read.
That would allow anybody to read this path,
and also you can say things like allow
write, of course.
You can also put these in commas,
so if you want to just allow read and write,
you can do it like that as well.
And as I mentioned, you can do also like
get, create, and other HTTP verbs.
Now in here you can put a condition.
So you can say I want you to only be able to
write to this if something,
and you can put anything in here,
but we're going to say request,
and then we'll say authentication
UID
not equals
null.
So what we're saying here is,
and this should be, of course, request,
so what we're saying here is that we only want to
allow reads to this path of the database
if the user is an authenticated user.
So we could do that for other places,
and write additional match statements.
So, for example, we can do another one,
and this'll be my other example.
Users, and then, again, we can say user ID
and then another path that we have is Meetings,
and then, in here, another sort of variable
for the document, meeting ID,
attendees, right, and then we can say
document equals
any of the documents in there,
and then control what happens when somebody
writes to our attendees.
So if you remember when you check into a meeting,
you're actually pushing information
to this Attendees section,
so that one has to be pretty permissive.
So we'll say read and write,
also that you may think that, well,
maybe I can just allow people to write
to this Attendees section,
but then when they checked in,
they wouldn't be able to see the list of users,
which is perfectly fine, it's a perfectly,
maybe you don't want anybody to see who else is logged in.
You want to be the only person to do that.
You should program that both in your application,
and you can also sort of control that as well in here.
There's a lot more stuff that you can do,
so once you're done with a set of rules,
you can hit Publish.
It'll take a second, and if there's any errors,
if you messed up, this is actually pretty cool.
It has a pretty good debugger in here,
so you can say allow,
let's see,
and I think what happened here is this should have been
allow write, not allow colon write.
So let's try publishing again, but it has
a pretty cool debugger.
So it looks like I made another error here.
And that should have been the same for up here,
it should just be allow read, allow write.
Now allow colon read and write.
So let's try saving this.
And now it likes it a little bit better than before.
You can also do things like check for
how the data is coming in from the register,
and the login, and even the check in
to make sure that actually the values that you retrieve
from those different forms come in a certain way.
There is a lot more that you can do,
so make sure that you check the documentation
for all the different options for your application.