Transcript from the "Validating Data Solution" Lesson
>> Steve Kinney: All right, so our goal was to insist on a title for a new post. All right, so we have this create rule here that I think we can just add to. So, we can say, we have the request.resource which is different than the resource. The resource.data.title would insist that the one in the database already had a title which is silly.
[00:00:34] Like that's not the concern of the new one coming in. But the request resource will be the one coming in. So, we can say, request.resource, let auto complete help us here, data.title.
>> Steve Kinney: Now, if we go in.
>> Steve Kinney: Maybe that didn't go fast enough. We'll see. It says title does not equal no. All right.
>> Steve Kinney: It could be.
[00:01:34] I think you're right. It could just be [CROSSTALK]
>> Speaker 2: Or is it, if we're sending undefined [CROSSTALK]
>> Steve Kinney: Or, let's find out. We're gonna learn together. Let's see. Let's go ahead and delete some of these.
>> Steve Kinney: All right, there we go. It was an empty string cuz input fields in the DOM are empty strings by default and not, in fact, null.
>> Steve Kinney: That'll also work. This will get you any false E value.
[00:02:20] We all learned something together today. [LAUGH] Cool. So this'll make sure that if this is falsely value, it'll turn it to true. Which will work. But yeah, so no it didn't work in this case cuz it was an empty string. Cool. All right, so now, we have the ability to authenticate the user.
[00:02:45] We have the ability to validate based on that user what's coming into our system and secure everything down. We did have this email authentication, I want you to talk a little bit about just in case, because there's a. I think it's worth going into because it's not as simple as the Google one, right.
[00:03:06] We need to do a little more work. Not much more work. But a little bit more work. But where I really wanna take this, after we get the email authentication set up, is these users are limited, right. They come with a photo URL, a UID, a display name, an email, I think we saw one or two other things, right?
[00:03:26] But that photo URL is the one we got from Google, right? So, if the user wants to change their photo in our application, we don't support that currently. If we wanted to store additional data on the user, that is problematic. There is a thing in Firebase called custom claims.
[00:03:49] Custom claims can get run from anywhere where you have like a full admin access or either from a node process or from a cloud function where you can put about a thousand bytes, a one kilobyte of additional data, on a user object, right? But that's still, that's mostly like, it's super useful if you have multiple databases and you wanna attach it to the user.
[00:04:09] Well, generally speaking for one it makes more sense to kind of have documents that serve as our user profile. If, in this application, we want the user to have a bio or we wanted to store the post that they favored is. Other things that we wanted to put on there, right?
[00:04:27] We are going to need some place in our Cloud Firestore to store it. So, a really great pattern for that is just to make documents that are based on that UID. Because UID will be consistent when the user logs in, and so, now basically every time they log in we can match them up with that document that has all of their other profile information.