[MUSIC PLAYING]
DAVID EAST: A blocking function, well,
blocks the authentication process
so you can process the user before they are created.
But why would you want to block the authentication flow?
Doesn't that sound like a bad thing?
Well, not at all.
Blocking functions give you more control
over the entire authentication process,
allowing you to reject users if they don't
match a specific criteria.
You can check does this user have the right email address?
Do they belong to a list of authorized users in Firestore?
Are they in the right GitHub organization?
This is completely custom to your use case.
But if we want to go further, we need to break it down.
Before we begin, I want to call out that blocking functions
are available for both Cloud Functions generation 1 and 2.
In this video, I'm going to be using generation 2,
but the concepts are the same and the code is similar.
Blocking functions work a bit differently
than your typical function.
So again, let's break it all down.
The typical serverless function structure
is that a function is triggered after an event or an object
is created.
A user is created and images uploaded, and so on.
And this is ideal for situations where you
know that the object is valid.
However, what if you need to inspect
the object before it is finalized and saved
to the system?
And that is exactly what you get with auth blocking functions.
Blocking functions hold up the event
before it can be completed.
This blocking time allows you to perform processing
on the server before a user is saved to this system.
A user record is not saved at this point in the process.
Only the data needed to perform the preprocessing
is surfaced via the blocking function.
Here you can perform any operations
to determine if they are a valid user
or if they need any other custom actions applied.
So how do we tell the blocking function to reject the user?
Well, with an https error.
An https error is imported identity library.
You construct a new https error and provide
a standard code and details.
The standard code comes from a list of predefined codes
that map to http status codes, such as unauthenticated,
permission denied, not found, and much more.
Check the link in the description
for the entire list.
These details can be anything custom for your use case.
Here, the email is invalid, so we're just
specifying that it's an unauthorized email.
Now, this scenario covers blocking
before an account is created, but we can still have
control even after this event.
Blocking functions allow you to block before a user signs in,
and this means that the user has been created,
but their authentication token has not been issued yet.
And what's the difference here?
And why would you want to block before signing in?
Well, imagine you need to check if a user belongs to a GitHub
organization before allowing them into the system.
But then sometimes later they are
removed from the organization.
By blocking before signing in, we
can check to see if they still belong to the organization
and reject the event if they no longer belong.
Now we've covered how we can block a user
from either being created in the first place
or before even signing in.
But what about actually accepting the user?
What do we need to do in that case?
Well, if you simply want to accept the user,
you don't need to do anything.
However, if you want to modify the user in some way,
you can return an object that specifies those changes.
The object can be one of the following fields--
display name, disabled, email verified, photo URL,
custom claims, session claims-- which only
works before a user signed in.
And this is great for the use cases
where you want to create the user
but then have them disabled if they
don't fit the requirements yet.
You can integrate with an external API
to set a photo URL for the user.
And of course, there's custom claims.
Now, I don't want to digress totally into another topic,
but custom claims are an amazing feature
that allow you to assign properties to a user that
can be used in security roles.
So I highly recommend checking them out.
So now let's deploy.
So let's make sure that you're in the functions directory
and then run npm run deploy.
This will ensure that all the needed APIs are enabled, zip up
your functions, and then finally deploy them out
to cloud functions.
So blocking functions are a bit unique
in that you have to register them in the Firebase Console.
Here in the console, I'm first going
to enable two providers so I can log in, Google and Anonymous
Authentication.
And next I'm going to go to the Settings panel
and set the functions for before account creation
and before sign in.
So now let's see it in action.
So now I'm going to log in with Google,
and it accepts it because my email ends in a google.com.
So now I hope you know what a blocking function is
and why do you want to block in the first place.
So if you want to know more about blocking functions
and see more blocking functions content, then drop a comment,
and let me know what you want to see.
But that's all for now.
And if you liked this video, make
sure to hit the thumbs up button and subscribe.
And I will see you all in the next one.
[MUSIC PLAYING]