In the last section we added in a little bit of logic to ensure that the user is authenticated before
we allow the request to continue into the body of the request handler at the very end of the video.
We said however that there might be many routes inside of our application where we require authentication
like this.
And so we don't want to have to be rewriting the same statement all over the time all over our code
base.
So in this video we're going to kind of generalize the logic right here and pull this logic out to a
single location that we can then make use of again in several other locations inside of our project.
So we get started with this actual brief factor I want to remind you about a little feature in the world
of express that we spoke about briefly earlier.
Inside this course and also in like just one or two videos ago remember that when a request comes in
from the user's browser it gets sent to our express application there can optionally be some number
of middleware wired up to our application.
Those middleware are used to inspect an incoming request and modify it or change it if it so wishes
the request is then taken and sent off to any different route handler that we might have inside of our
app.
Now thinking about this middleware thing in the context of our problem remember it's some function that
takes the incoming request and kind of messes around with it just a little bit before the request is
sent on.
So thinking about our problem here we've got all requests coming in.
It goes to the Express application the Express application sends the requests to the passport middleware
where the current user is assigned to the request body or to the actual request object and then immediately
after that is when we want to make sure that our user is logged in.
But in this case unlike some of the other middleware that we've seen that we previously wired up inside
of our index not just file.
So like these for middleware right here unlike all of these we only want to run this particular check
the Slyke little check to make sure that a user is logged in on some very particular route handlers.
So we do want to check all over the place we want to just do this in some very particular route handlers.
So here's what we're going to do and this video we're going to create a new middleware that we will
use to make sure that a user is actually logged into our application.
We will then make use of that middleware with only some very particular request handlers specifically
the ones that we want to have ensure that a user is logged in before they actually access that given
request handler.
So we're not going to use this middleware that we are going to author in the same way that we did all
these others these other middleware as were being used for every single request that comes in to the
application.
We want to apply ours to just some very particular routes.
OK.
So then mind let's give this a shot.
Now in our application we might end up having many different middleware.
So I'm going to decide to kind of centralize all of my middleware so that I might create that are accustomed
to my project inside of a single directory that I'm going to call middleware is inside of that folder.
I'm going to make a new file called require log in.
Yes.
Now remember our naming convention throughout our project if we export a single function or just kind
of like a little piece of code a little snippet.
We use a lower case r.
If we are exporting a class of any type like a Component class or a model class or whatever it might
be that's when we start to use a capital letter.
So we have a lower case are here which indicates that we are going to be exporting a function and that
function will be the middleware.
OK.
So let's see how we do this at the very top.
We're going to define and immediately export an arrow function.
So we'll say module exports place our parentheses like so now like I told you earlier and middleware
is a function that takes the incoming request and has the ability to kind of modify it inside of the
middle where body inside of this function.
So we're going to take in three different arguments that kind of assist in that process.
We're going to take an argument called rech which is the same request object that we've been working
with all along.
We'll take in the Reds argument which is the same as the response object that we've been working with
all along.
And then we've got one new argument that we're going to put on here called next next right here is a
function that we call when our middleware is complete or like all finished running.
The next middleware you can think of is kind of being like that done callback that we saw inside of
some of our passport code.
The reason that we're calling it next in this case is that our application remember it might have many
different middleware inside of it.
And so the next key or the next function is name the way it is to kind of indicate when you call this
function it's going to pass the request off to the next middleware in the chain.
So in other words after middleware number one right here finishes running it will call next that passes
the request on to the next middleware in the chain.
OK.
So for us the logic that we have to put in here is pretty darn straightforward.
Again we just want to check and make sure that the user is signed in.
So just like we did inside of our handler will say if there is not a user that has been assigned by
passport already then immediately return with a response that has a status of 401.
Which means forbidden and will send back a message that says air you must log in like so.
OK.
So this right here very clearly kind of terminates the incoming request it says hey something is wrong
with this.
We want to bail out of your early so returned from this middleware.
Take the response object and send a response back right now.
Now remember that we just spoke about how at the very end of every middle where we have to call next.
Well that's only if we actually truly do want to go to the next middle where if something happens in
middle we're number one that is kind of indicative of some pending error or something like that.
Like exactly our case a users not logged in.
If we if we let this request go on any further the server might crash which would obviously be very
bad.
So what we want to do is say hey there's something wrong with this request something is going very wrong
here.
Just stop the entire middleware chain.
Do not go to the request handler stop the request right now and immediately send back response.
And so that is exactly what we are doing right here.
However if the user is logged in.
So if the user does exist if passport has found a user inside the request that is the case in which
we want to allow this this request to continue onto the next middleware in our chain or potentially
the actual route handler itself.
So at the very bottom we'll call next like so.
So this essentially says if there is no user something is wrong with the request immediately return
and send a response back to the user.
Otherwise hey everything looks good.
Let's let this user continue on to the actual request handler.
OK.
Now onto the very last step here.
We have completed our middleware.
We're now going to wire it up to our very particular route that we want to apply it to.
So the way in which we wrote our middleware right here we could wire up to our express app object inside
of our index not just file where we wired up all the others.
So the where we just created it could very easily be used inside of this with our app object to use
the app don't use call right here.
However we have said that only on some routes should a user actually be logged in.
So for us we're not going to say that every route has to go through our middleware.
We're going to say only the API slash stripe route does so only this one is going to actually require
a user to be authenticated.
So to use that middleware inside this request handler will first require in the middle where at the
top will say Konst require log in is coming from up 1 directory middleware is required log in and then
to specify that we want specifically this request handler right here to run this middleware before it
goes to the request body right or to the actual request handler logic itself we will add in required
log in as a second argument to the handler.
So right after API slash stripe will say require log in like so and then we put down the actual request
handling function as the third argument.
OK.
So quick couple of things in here.
You'll notice that I did not invoke require log in.
It is a function yes but we're not calling it like this and we're not calling it right now because we
don't want to require log in or to run this middleware.
The instant express loads up or we execute inside of our terminal and run this code for the very first
time what we're doing right here is we're saying hey express any time someone makes a post request to
this route.
Here's a reference to a function to run whenever a request comes in.
So Express takes the reference to this function and express will call it internally or call it itself
whenever some request comes into the application.
Now the other thing I want to say is that I did kind of I said very clearly like oh yeah we want this
to be the second argument and we want this on to be the third argument right here.
Well to be honest all these Raut handlers like appetite get amped up post or whatever take an arbitrary
number of arguments so we could pass in as many middleware is here as we want.
The only requirement of is of express is that eventually one of the functions inside this list right
here like be it require log in be it some other middleware we put in or be at this actual function that
we defined ourselves right here.
Eventually one of these functions has to process the request and eventually send back in response to
the user.
Thats the only requirement of Express doesn't care how many little functions you toss in here just eventually
one of them has to actually say OK heres the actual response here you go send it off to whoever made
the request.
That's the only requirement.
OK.
So that's pretty much it for putting our middleware together.
Now the very last thing we're going to do inside the top of this request handler we no longer have to
manually check this with the if statement that we just put together.
So I'll take that out and we are left with just this like so.
So now it's very easy for us to secure any route inside of our application with this required log in
Middleware.
We just have to require it in.
And then before we actually run any logic on the incoming request we say hey take the request throw
it into this middleware right here.
Make sure the user is actually signed in.
And that's pretty much it.
OK.
So I think that our billing stuff at least some server side is all pretty much wrapped up.
So I think the very last thing we have to do is to make sure that back inside of our application the
number of credits that the user has is somehow visible inside the head.
So let's flip back to the client in the next section and take care of that last task.
So I'll see you in just a minute.