Firebase with React, v2 Writing Security Rules
React devs might find this archived course helpful to reference, but this course has been updated! We now recommend you take the Firebase Fundamentals course.
Transcript from the "Writing Security Rules" Lesson
>> Steve Kinney: Let's go ahead and figure out how we do this. So we can go and you see there is this little exclamation point, next to Rules, that's because it's warning us that it's trying to be very clear that this isn't good. This was fine for development but ultimately, not a thing.
[00:00:19] All right, so we kinda already know a little bit of the shape of our data. We know that there are posts, so we could say match.
>> Steve Kinney: We'll say /posts.
>> Steve Kinney: Maybe a postId there too, and we'll allow anyone to read. Go ahead, query the whole list.
>> Steve Kinney: That's fine with us.
[00:00:50] Get a specific one and we'll allow a write.
>> Steve Kinney: Only event that the request.auth.uid is not null. If they're not logged in, the user is null, if they are logged in, we'll have that user object that has the UID, the display name, so on and so forth. Cool, and then you can either hit Publish or you can hit command+S, and they take a minute to propagate, but generally speaking, it's pretty quick.
[00:01:29] So if I go ahead and log in.
>> Steve Kinney: New post, I am secure. There it is. I sign out.
>> Steve Kinney: Another new post, not going to happen. We're gonna see the error in our console because we don't really have error handling. But you can see it's very angry at us.
[00:02:02] And the error message is missing or insufficient permissions, which makes sense because we put in security rules and the rules say that you can't make things if you are logged out. So, mission accomplished, right? Now, obviously we'd love to catch that error and actually display a more helpful ui.
[00:02:21] But that kind of, like, is the major, like of it. The other thing I wanna do is, right now, whether I made the post or somebody else made the post, I can delete any posts I want, right? We wanna make it so that a user can only delete their own.
[00:02:39] Now, this is gonna be a little trickier cuz right was remember all three, is create, is update, and it's delete. So we gonna need to split this one out a little bit just using right as kind of a sledge hammer here is not gonna be good enough. We'll go ahead and we'll say, okay, they can create If the request.auth.uid does not equal null.
[00:03:01] But if they want to, let's say, update, update we had the star, right? So let them create or update, right, if they're logged in. However,
>> Steve Kinney: They can only delete.
>> Steve Kinney: If the request.auth.uid
>> Steve Kinney: Now remember we made that, this is gonna blow up in our face a little bit cuz we never actually used the current user.
[00:03:38] And we're still using some default like 111 user ID. So I won't be able to delete any of them once we implement that because that's how I developed the database. But we'll say okay, the request.auth.uid look at that resource. Whatever document we're trying to get and we have that user map that had a UID field on it.
[00:04:18] If these two things don't match, then the user will not be able to delete one, right? So ideally, we start out with very locked down permissions and we slowly begin to open them up depending on what the user needs. Yeah.
>> Speaker 1: Under the current rules, would I be able to edit someone else's-
>> Steve Kinney: Yep, you would. Right, and so we could then start to have further conditionals in there and build it out a little bit as well. Yeah, if we have the UI for doing that, you would totally be able to edit the contents of somebody else's post.
>> Steve Kinney: Right, so we might do something like
>> Speaker 1: We create an object that cannot be bunched together there, it won't work?
>> Steve Kinney: Create we can separate them out, right. And we can start to write a conditional in here that got a little bit more granular, right? So create update if the request is not null and like the title and content match the previous version, right?
[00:05:19] So you have the request.resource.data and the resouce.data, you can make sure that, okay, they're only, yeah. They can't do this one, this one, this one. It's only this one that they can change. So you can get increasingly granular too.
>> Speaker 1: Would it be sensible to just make update follow the same rules which is you can only do it to your own and so just move update down into-
>> Steve Kinney: You could. That would break the ability to star them in our current data model, right? And so there's two choices there. Either, right, you could have a separate collection, which is like user favorites, right, that have a user and a favorite. So you can say, give for a given user, or those who are given post and those favorites, right?
[00:06:03] And so you then query that and so you can get a little more granular sometimes not necessarily in the Security rules, but in the way that you structure your data, right? And so when you get to those specific use cases, it does come down to, do I write more sophisticated security rules, or do I sit there and rethink how I structure some of my data, right?
[00:06:21] Cuz sometimes querying, I know SQL databases can be a little tricky, cuz you basically start at a given cursor and go in a particular order. So stuff like Ors don't really work. So sometimes, you have to create these collections that are two keys so that you can sort them in a particular way and run through a set of them as well.
[00:06:40] We're gonna keep it a little bit naive for now because nothing will make your brain melt like getting really complicated with some of the security rules. So, we have these in place. We'll let them update right now if they are logged in. We'll let them only delete if it's their own.
[00:07:03] We do need to change a few things real quick. Let's go ahead, we'll publish those. Let me go into my database. I'm just gonna delete these documents cuz they all have this like garbage username here. So delete all of them. From the admin dashboard, you can do whatever you want.
[00:07:22] Security rules don't apply to you, right? And that is also true on any of the the server, I'll just call them the server side code but the console is not necessarily server side but it is privilege access. You're lambda functions can also have privilege access, sorry your cloud functions.
[00:07:40] It can also have privilege access and do those things as well. Or if you hold down your secret key and run like a node process. You can also go ahead. You don't necessarily need these permissions, your users do, right? There's always an escape hatchway, you have super powers.
[00:07:56] You can do whatever you want.