Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Simplified)
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranรฎ)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
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 of our application.
I want to take a moment to review the rules to understand better what's going on.
You can navigate to the rules by going to your project's dashboard in Firebase on the sidebar under
the developer section, click the database menu item, then switch over to the Rules tab.
Firebase has an editor we can use to modify the rules.
You may notice that the syntax is similar to Java Scripts object syntax.
Firebase adopts similar syntax, but there are differences.
Let's go through the rules line by line.
The first thing that's being set is the rules version variable.
It's being set to two.
The version must be set before you can proceed to write some rules.
The version determines the syntax you may use different versions, support different features.
Version two is the latest version.
After setting the version, you can start to create the rules.
Creating rules is similar to creating CSS properties.
I don't mean that syntax wise.
In CSS you need to make a selection.
Once you've made a selection, you can start to add different properties.
The properties are applied exclusively to the selection.
That same idea is represented here.
The first step is to select your resource.
The rules should apply to.
After making a selection, we can begin to add the 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 is selecting a service.
I mentioned in the previous lecture how Firebase transitioned from a database solution to a back end
solution.
Firebase offers various products.
It calls services.
You can have different rules for different services.
The service keyword allows you to select a service.
In this example, we are selecting the cloud dot firestorm service.
This service refers to the database product.
After selecting the service, we're adding curly brackets.
Anything inside the curly brackets is how you can group selections or rules.
Then 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 be used to 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 database is 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 Fire Store 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 to the name
of the database.
The last segment in the path is the documents directory.
Documents is the terminology for the objects in your database.
We'll discuss documents more in depth in a later 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 wild cards.
This wild card means the rules inside this condition will apply to any document.
The last thing we're doing inside this condition is adding the rules.
We'll want to have different conditions for reading and writing.
Add the following if true.
After making any changes, you will need to publish them.
There's not much else going in the rules.
The way they're set is fine for now.
If we ever do 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.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.