Firebase Rules Tutorial for your Realtime Database! [PART 1]

hey guys and welcome back to you Nico Deb today we will talk about fire based security rules for your real-time database first of all thanks to this guy for suggesting me the idea I actually wanted to do this video in a while but then I just forgot and this guy reminded me so thank you if you enjoy this kind of content you can leave a like for more I'm also starting a new series on machine learning and I'm doing new episodes soon so you can also check that out if you're interested but now enough self promotion and self plug let's start with the video ok so in this video I will talk about first what rules are and what they are needed for but also I will talk about anything that you can do with rules or most of the things that you can accomplish ask off the time I'm making this video so it's gonna be a good reference point for all of you now and divided the video into chapters so maybe if you need the explanation only for one specific thing you don't need to watch the entire video but you can just go but you can just go to the chapter you like in particular you need in particular the chapters are in the description anyway let's start with creating a database and as you can see it tells you if you have to start it in locked mode or test mode for now let's start it in test mode so basically this means that the database is readable and writeable to and from everyone ok so we have our database but we actually don't need to worry about inputting any data or doing any any any code that inputs any data I actually have really made a video on that today we only need to worry about this tab the rules of the database now as you can see the rules of the database and exactly what we defined at the beginning starting in testement the read is true for any user and for any point on the database and so is the right now when you see these rules the formatting might sound or look familiar in fact these rules have none other than a JSON file as you can see they are formatted like a Jesus but they are not plain old jisun because they can actually hold javascript like expression which means that here is sort of true I can put a JavaScript like a spread expression just like because equals two and then if I publish the rules so I change them this will actually still run and this will translate to true but now before actually talking about the rules and how they work we actually need a way to check if you know we can read the database or we can write to the database now check if we can leap to the database it's pretty simple you can just do it on your browser now I don't recommend it but you can just do it on your browser you can copy this code right here this link and you can open a new tab and just do this just paste it and then do doc gisun so you get the road date out of it and as you can see we're gonna get noble okay because there is no data so if we add some data we are gonna get the data as a jason now if we were to set this to false or maybe to qu equals equals 3 and we reload again we're gonna get an error permission denied but this is not the best way to see if your rules world and firebase made it really really simple for us to test around our rules we can just do it by clicking the rules playground button now once you click the rules playground you can choose what type of action you want to perform on the database so if you want to read set or update now as you can see if I do a set okay and I run this I will get simulation allowed because the write was set to true but if I make a read and I run this it's gonna tell me that no I'm not allowed to perform this action so this is a really simple way to test any kind of request to your database also you can choose the location where you want to do the request right now we are just doing it at the main branch of the database but we could actually go into some database children's like users Nico and then just try to get to its nickname okay and we can run and see that we still got denied because the read is false we can also get authenticated and we can authenticate as any provider we want which could be anonymous as Facebook provider Google provider we can even put a custom user ID and that's it then we can run the function and see if something it's different my naturally nothing is different because right now we are disallowing three on everywhere in the database okay so we talked about the rules playground and we talked about the rules in general the last thing I want to show you before actually getting into the code is monitor rules so from this tab right here you can actually check the analytics on your rules and you can see if over time how many allows were made so how many requests I've actually gone through and how many requests have been denied you can also see how many errors arrived in the database and basically errors are cooler if there is something like an expression that doesn't make sense they're in the database that throws an exception all right now that all of this is done let's start talking about our rules let me just zoom this in so you guys can see it more okay there you go so the first key concept of the database rules are the branches so basically right now we are defining a rule on the entire database but we don't actually need to do that we can only define a rule on a specific branch or a specific folder I will call it branch from now on of the database so let's pretend it's in our database we have a bunch of different folders okay we have the secret folder okay I know I said branch on I gotta call it branch and I have the user's folder okay we have the user's folder okay and now these two folders can have different rules so I can put different rules in each folder so maybe right here let me copy this here so maybe the secret folder cannot be written from anyone and also cannot be accessed well the user folder can be read by any user but it's not writable and now if we publish our rules this is actually going to go through and if we go in the rules background you can see that now if I do a request on the entire database I'm gonna get denied but if I do a request expecially right here on secret I'm also gonna get tonight because secret is not accessed but if I do it only users and then hit run the simulation will be allowed okay so this is one thing you can do with the rules by default the read and write rules are always set to false so if I do this thing right here and remove the secret the rules are gonna basically stay the same because we couldn't still write or read the on secret anyway in fact if I go to secret I'm still gonna get night now another cool concept about rules is the rules cascade this basically means let's do an example we have the user's folder okay and you can read in the user's folder but you cannot writing it okay let's say that we have a specific user inside the users folder we can call him user one okay and now for this specific group user because this user has been nosey okay this user cannot read the database or or I mean nobody can read the information about this user on the database because the reader is going to be paused now what do you think will happen when I try to request the read on the user user one now what you might think is that the request will be denied but actually the request is allowed and this is basically what I mean with rules cascade I allowed the read access in the entire users folder so this data right here this attribute is actually getting ignored because the read was already completely allowed so this is something you have to be really careful about when you're writing your rules if we were to be in the opposite situation so right here the reading is false and right here is true and we publish our rules and we try again as you can see now the simulation will be allowed so basically you can imagine this like big an or gate so all of these rules are put together as sum or so this means that just one of them needs to be true for the operation to go through all right so now you know about the rules cascade before continuing another key concept to keep in mind when you're writing rules is that roots are not filters now what do I mean by this basically what I mean is that if I have a situation right here okay where I have my rules I have my users and the user 1 and I see that the user 1 is set to true if you have a quick glance at these rules you may mistakenly believe that the entire user folder can be readable now this illusion is even better if I add multiple you now the formatting is a little bit weird on this on this editor for some reason okay there you go but yeah you may think that since both users user 1 and user 2 have the reading aloud then the entire user folder can be readable but you would actually be wrong as you can see if I do a request on user 1 it's all good and then D but if I do our request only on the users folder it's not good I I don't the team gets denied I'm not getting any users so this is something you have to keep in mind if you want the entire folder to be readable you are up to put the rule right here and then you can actually remove it from here because you know it's already up there so we don't need it as I said rules cascade ok awesome we learned that now the next step will be to understand some firebase rules variables that are there for us and then we can use anywhere in our rules food in order to get more information about the request or our user let me actually add one more here so basically now will return you a number which is the timestamp of when the request was made maybe you want to limit your request that was certain time so maybe if you request after this time you cannot go through and with this now you know exactly the timestamp when the request got through now this out variable will give you information about the authentication of the user if the user is authenticated which provider is using even what user ID and the user ID if you guys don't know is an identifier that specifically targets we can say it's specific to one user so you can specifically know which user is authenticating and you can also get the user token and you might say Nico why do I want to user token well because you can also set some claims which are soft some flags so to this user token now I'm not actually going to get into outer set claims for your user token I will leave a link into this picture that you can check out in order to do that but basically what that will allow you to do is that once you have the owl token you can just do dot is owner attic and this expression will return true if you add set the flag its owner to the user when he signs in so you know a lot of stuff you can do by knowing if the user is authenticated or not and all of his information so basically everything you can get is out that provider out dot UID and out dot token or at least these are the main things ok query whoever it will give you information on the query that the user is done on the database this means that you will basically know what settings are what attributes the user gave the request meaning you can know if the user ordered by the request by children by key by value you can also know how many results the request wants at example you can check if the limit to first is equal to fifty or is less than 50 so this is basically saying I mean this is not saying anything these are not actual rules because we're not in the G zone I'm just typing it right here for convenience but this expression will return true if the user has done a query which - less than 50 values so you can limit the amount of data that is trying to get retrieving from that location in the database all right and now we get into data new data and route these three teams return actually the same object and they basically return our route dark a snapshot I'm sorry not to query let's not get confused I mean data a new data and route now a route that a snapshot can give you information about a specific branch on the database as you can see the data actually ask a bunch of attributes which are like is children or if the data exists if the data as children I think that it's also parent yeah you can get the parent of the data if it exists and then you can continue the parent is gonna be another data snapshot so you can get the parent of that ooh phone number okay that doesn't make much sense but yeah you can get the parent of that and all of that now basically root will return you the snapshot of the entire data base so basically at example I can go - I don't know settings say that I made a branch of the database called settings and in these settings I made a custom setting which is allowed reading ok and then I can check it's the value of this setting is equal to true and I can see only if the value is equal to true then you allow the request if it's not you don't allow it now theta basically does the same thing but instead of giving you the root of the database so the start of the database the entire database it only gives you the database at a location where you're doing the request and it will give you the old data so basically the data before the request actually went true let's say that it was a write request and so it was setting some data on the database this data will be the old one on the contrary new data will be the same as theta but it will give you the new data so the data that the branch will be set to after the request is made okay great and the last thing is far now the best way to show you what this thing actually is basically a wild card is by doing an example now let's say that in the users folder I have a bunch of users ok but I want to allow read to every user ok every single user so you might say Nikhil you you can just put it right here ok you don't need any users you can just do this and boom ok any users but one so I need to do an exception for one user so naturally as we learned from before we cannot just do this so let's say that the user name is nicko so we're gonna go with b-cup this is not going to work because the rules cascade so Nikko will still be able to read its own branch well what we can do is use the wild card so basically we remove these and we see that the data under users Nikko cannot be readable but also ok every other data every other children and we can say at example user ok every other children is readable so basically this wild card will apply for any generic children which is not equal now if we publish we can actually test this out let's do a read request to users is not going to work because I didn't allow the entire users to be readable let's do it - Nika and we should still get banned yes because me the ball is false but now if I do it - anything else it will actually go through because as you can see the wild-card made it come true now something interesting about this wildcard is that it's actually also a variable so this means that inside this expression right here we can check and you know we can communicate it to this variable so we can just do this and we will call it but I need the quotation marks in order to do the expression so we could check an example if this variable it's some value and only make the reader go through if the variable is some value so an example only if it's neutral now this is a little bit weird I'm able to do this but I just wanted to show you as an example let me publish this so now okay okay well I still need quotation marks for Niko I guess because I need it to be a string there and now the read shouldn't go through because this is not Niko yes but if I make this and it run it will go through because basically this user right here is liquor so user will be Niko now just a clarification in case you're confused this user doesn't like it's just the name of the folder okay doesn't have to be a user it's not like this is just the example I made this has nothing to do with authentication in order to do stuff with authentication as I said you have to use both this variable that will tell you that you know the actual ID of the user the provider and the token and now I will give you an example of actual rules that you know matter and now I will give you an example of an actual set of rules that you know actually are the rules that a lot of people use in their application so as you can see we are making use of the wild card of the variable and also making use of the out so what does this do basically in the users folder okay in any generic folder underneath the users folder a user can read and write to that folder only if it's user ID is equal to the name of that folder now the beauty of this is that as I said before the user ID is specific to each user so this means that every single user as a folder to so every single user can store data on his folder and nobody can read it so every single firebase authentication user will be able to have its own space where only he can read and only he can write and this is really useful for a lot of apps think an example I don't know I'm just saying adopting Google Docs okay a user needs this safe space okay probably under users and use its user ID where it can save its document and nobody else can see the document nor can replace it all right great let's actually try this out because as I said before the roots playground actually allows you to put a custom user ID so if we go in users link on now we are in users and this variable is going to be Nico and we do run it's not going to work because our user ID is HelloWorld but if we make our user ID Nico then it is going to work because our user ID is the same as the variable name also just like an FYI let's pretend that right here in users we actually have the public information of a user so what we want is that nobody can replace this data except the user himself so this is actually good but we wanted everybody can read this data so we can actually set this to true this is just another example but now it's not really a common practice to set this to true without you know any restrictions but you actually could do is check if an user is authenticated and only if it is authenticated then it can read the database basically you are forcing people to create an account in order to get data from your database I don't know just like Facebook would be hiding some posts if you are not signed up so right here we can just do if the out i ID with the author ID is different from no so we just need to do this check and then if you're not authenticated that is not going to let you read this but if you are authenticated with any user ID it will let you pass and let's see if this work now I'm authenticated and I have the user ID of Nico and let's see if he makes me read yes but even if I have any other user ID I will still be able to read it but if I'm not authenticated at all I would not consume as so now there are still a bunch of stuff that I want to talk about on firebase rules but I've noticed this video is getting pretty long and I want to get the videos as short as possible so they are really back sides and you can watch them you know whatever you want I'm gonna make a part 2 of this video really soon that will show you whatever else you can do with these rules there are actually a few things that I didn't showcase or I didn't go into detail of and maybe I didn't do many examples such as the rule dot validate and also the rule which is not really a rule but we will talk about it later index of also I didn't talk about how you can publish these rules not from here but from anywhere else like from your computer you can just deploy any firebase rules you want so we're gonna also get into that in the next video if you really enjoy this content as I said leave a like because it would really support the channel also leave a comment if you have more suggestions and subscribe if you're new thank you ever so much for watching this video to the very end I really enjoyed it and I'm gonna see you guys in the next one see ya

Channel: uNicoDev

Views: 43,476

Rating: 4.9346557 out of 5

Keywords: unity, game, gamemaking, tutorial, how to, firebase, firebase realtime database, firebase realtime, firebase database, realtime database, rules, security, firebase rules, realtime rules, secure rules, firebase rules 101, webdev, app development, typescript, javascript, lesson, database, data security, validation, json, data integrity, nosql

Id: dx_gkSb-Ch0

Length: 21min 15sec (1275 seconds)

Published: Wed May 13 2020