Firebase Fundamentals

Authentication Triggers

Firebase Fundamentals

Check out a free preview of the full Firebase Fundamentals course

The "Authentication Triggers" Lesson is part of the full, Firebase Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

David walks through a continuation of the Admin SDK example by checking if a new user has any pre-existing collaborator requests and, if so, adding them as collaborators. A brief discussion regarding the auth triggers onCreate and onDelete and the v2 blocking functions beforeCreate and beforeSignIn.


Transcript from the "Authentication Triggers" Lesson

>> And then when this email joins or in this email when this user joins,with that email they'll have a user record created. And one of the things I could do is say hey welcome to the system. Let me look to see if you have any collaborator requests that are sitting around.

And let me just add you as a rule to all of this. This is something you could also do on the client. But it's also a nice, actually that you couldn't do it on the client because of the security model. But there are certain ways where sometimes you can add things on the client to bootstrap up their data set.

And other ways to write this query, I can use a collection group query. Because I can assume that all budgets are going to have a sub-collection of collaboratorRequests. So by writing a collection group query, I'll look across all budgets and say how many budgets have invited you probably anywhere between one to three max.

But that way I can structure my data nested like that and then still search across all of them. So to write a collection group query, I'll write a groupQuery. And that's firestore.collectionGroup. And that is, I'm just gonna copy of it and because I type out everything collaboratorRequests. And then from here, I want to do collaboratorRequests.where and I can say the uid, my goodness.

Write that down here where the uid is equal to the new is, my gosh, is equal to the new users uid, which we're getting back here on the create. So that gets all of the collaboratorRequests. So let's get those const snapshots, groupQuery.get and we're basically gonna do the same thing as we're doing here.

We are going to add them, but we're gonna do that in a loop. So we're gonna say snapshots. We could do this in a batch as well. So const batch is firestore.batch and then now for I need to await it thank you VS code. And for here, I need to know what budget I meant.

So the way this works is is this is a document reference. And so each document reference this is at the document level of collaboratorRequests because we are here doing queries for collaborator extra as my query for collaboratorRequests. So I know that the parent of collaboratorRequests is the budget ID.

So I wanna kinda get the parent document right here. So I can say budgetDoc is d.ref.parent. And so now I know I'm at the budget level and then from there I can say the collaborate or call or I can use a collaborator Doc is budgetDoc.doc of the user's uid.

So user records user that uid now, which is just this right here, once again, it's going to be user.uid. And then from here I can just say collaborator. I say batch.set of the collaboratorDoc and then set the role to collaborator. And then instead of returning this one, I'll return a whole batch return batch.commit.

So basically what's going on here is I'm getting all of the potential collaboratorRequests across all sub collections where their uid is equals to the new user. I'm going to run that query, create a batch loop through all of the query results, get a reference out to that collaborators sub-collection underneath the budget.

And then set it within the batch and then return it as batch.commit. So let's save and let's create a user. All right, so let's go into authentication, let's add a user, let's set this as Darla East, my dog's name is Darla, for what it's worth. So, while I'm thinking up of things to use for demo data, I just look at the furry creature on the ground.

And then I'm like that's what I'm doing. and password 1234Firebase and let's save fresh. We have Darla right here. I made a mistake. I'll have to do this again. I did not add the user to the collaboratorRequests. All right, so we'll do another so So now we gonna wait for this user to be created.

And I can copy that right here, then we can go into authentication, clear that, add a user Darla again, 1234Firebase. Save, all right, so let's go out to FireStore, collaboratorRequests that's their, see, won't see anything yet it should be there some probably, yes there is what the old one, okay?

So it says users created, so it triggered it, so I did something, right? One of the mistakes I made was that I said, where uid is equal to user.uid that's not, we have to talk where email is equal to I was thinking in uids and I couldn't get past that.

So this will pull back the collection. This will go through and get those snapshots, we'll create a batch. Loop through each snapshot, go through and get the .parent. So we can create collaborators so we can get to the budget, go to its collaborators and then get the doc of the new user's uid.

And then from there, we can set that roll of collaborator in the batch. So now, let's go and then return that shot commit because functions need your promise to be returned. Now, save and let's trigger it. All right, so let's go through we have a collaborator across for

So I'm gonna copy that, authentication I'm gonna delete the user so we can trigger it one more time. So Darla, again and that's, 1234Firebase. Now, when I save we have a new user. If I go into Firestore, go to good budget, go to collaborators, we have the two now have a new one.

For each one, you can see that our logs were good. So that is a lot of power at your fingertips with Firestore versus with Cloud Functions. And one of the things to that you can do with Cloud Functions is are we did an onCreate off trigger. You can do an onDelete off trigger where you can clean up anything that's going on.

But also something that I'm not gonna cover today but I just wanna talk about because it's super cool is there's like a new type of function called before create and before sign in. And these are blocking functions. So the way that these work these are v2 only. But when a user goes to create an account, you can block on that account creation and you can say, hey, I'm now only gonna allow this user, if their email is a part of my company's domain.

Or if they belong to a GitHub repository that I can check in the API. So you can do a lot of custom checks in here. And the same thing with before signing every time before user signs in, you can do some custom checking there as well. And so the token will not be issued until that sign in function returns.

So it's a really nice way of doing a lot of complex custom logic.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now