In this lecture, we're going to review the rules generated by Firebase.
The rules we selected allow anyone to read or write to the database.
It's not an ideal set of rules, but it'll work for the development phase or our application.
We should review the rules to have a better understanding of what's going on.
We can navigate to the rules by opening the project's dashboard on the sidebar under the build section.
We will click on the Firestorm menu item.
Lastly, we can switch over to the Rules tab.
Firebase provides an editor for modifying the rules of our database, we can tailor the behavior of
the database by configuring the rules.
We're not forced to keep the default rules.
The syntax is similar to JavaScript object syntax.
Firebase adopts identical syntax, but there are differences.
Let's go through the rules line by line.
The first line is configuring a variable called rules version.
It's being set to two.
There are different versions of syntax features.
We want to use the latest version by setting the rules version variable to two.
We will be able to use the latest syntax features different versions support different features.
Version two is the latest version.
After setting the version, we can start to create some rules.
Creating rules is similar to creating CSS properties.
I don't mean that syntax wise.
In a sense, you need to make a selection.
Once you've made a selection, you can start to add different properties.
Properties are applied exclusively to the selection.
That same idea is represented in this syntax.
The first step for applying rules is to select where the rule should be applied to.
After making a selection, we can begin to add rules.
Rules can be applied universally.
In some cases, you may want to apply rules to specific resources in your database.
Firebase provides everything you'll need to apply rules to different resources.
The second line in this editor is selecting a service I mentioned in the previous lecture how Firebase
transitioned from a database solution to a backend solution.
Firebase offers various products it calls services.
You can have different rules for different services.
The service keyword allows us to select a service, and this example we are selecting the Cloud Firestar
service.
This service refers to the database product.
After selecting a service, we're adding curly brackets.
Adding curly brackets will group rules together.
Anything we write inside the curly brackets will be applied to the selection.
We don't have to start writing rules if we want.
We can continue to write selections.
Up next, we're using the match keyword.
Any time a request is made to the database, it must be to a specific resource.
The match keyword can check if a request is being made to a particular resource.
In this example, we're checking if the request is being made to the databases slash database slash
documents resource.
The databases directory is where databases are stored.
You can have multiple databases for a Firebase application.
Currently, we're on the free plan.
We're allotted one database.
If you'd like to have multiple databases, you'll need to upgrade to a premium plan.
We won't need to upgrade because one database is more than enough.
Every database is listed under the Databases directory.
Afterward, we're using a placeholder called database.
Firebase will replace this placeholder with the name of the database the request is trying to access
if you want to apply a set of rules to a specific database.
You'll need to change this placeholder to the name of the database.
The last segment in the path is the documents directory.
Documents are the terminology for the objects in your database.
We'll discuss documents in depth in another lecture.
Inside this condition, we're making another condition.
The condition is checking if the document is equal to two stars.
Two stars are treated as wildcards.
Therefore, we're selecting any document in our database regardless of the name.
After making these conditions, rules are being applied to our documents.
This rule allows anyone on the internet to view, edit and delete data in your database.
Every single piece of information in our database is accessible to the outside world.
It is helpful for getting started, but leaves us vulnerable to attackers to mitigate damage.
These rules expire in 30 days after the expiration date.
Requests to our database will be denied.
It's possible that you may not be able to finish this course in 30 days.
It's perfectly fine if you aren't able to finish.
You don't want to be locked out of your database.
You can modify the rules to extend the expiration time in the condition.
We're calling a function called timestamp that date.
It has three arguments.
The year month.
And day, you can modify any of these values to extend the expiration date after making changes, you
will need to publish them.
We're finished with reviewing the rules for our database.
The default configuration will work for our project.
If we ever need to modify them, we will.
In the resource section of this lecture, I provide a link to the Rules Documentation page.
Everything you'd want to learn about rules can be found here.
From the syntax to how you can test rules, I recommend checking it out if you would like to learn more
about security rules.