In this video we're going to create that second middleware.
The goal this Middleware is to reject any incoming request the user is not logged in.
So it's gonna be very simple in nature.
All we have to do since we already put that other one together is take a look at the recurrent user
property if recurrent user is not defined.
That means the user is not logged in.
So we are going to reject the requests or essentially respond with an error.
So let's get started on that middleware right away because it's gonna be pretty easy to put together.
All right.
So back over here I'm going to find my middleware directory and I'll make a new file inside there called
require off to yes then inside if you're at the very top.
Once again we will import request response and next function from express well then put together a function
called require off and once again for the argument list we'll put in Iraq of request rez response and
next next.
Function so we are going to really make a big assumption here we're going to assume that we will never
use the require auth middleware without previously running the current user middleware.
So in other words by the time this request shows up inside of require off we should have already checked
to see if there is a Jason Webb token present we should have already attempted to decode it and set
it on the recurrent user property.
So again if recurrent user is not defined that means we need to reject this request and respond with
an error so we can do something like if there is no recurrent user property then we should return early
and we can do something like a resort send or a one a for a one you will recall means forbidden And
we can't excuse me that should be a status we could send back something Alex like our common error structure
remember that com their structure is that structure we encoded it in all those customers.
Now as soon as I start looking at this we're kind of going back to that same similar scenario when we
were talking about all those custom error things where we are trying to manually write out how to respond
or how to handle some kind of air condition.
So as soon as I see this right here I think maybe rather than trying to manually write out the response
right here maybe you would make a lot more sense to create yet another custom air inside of our project
to handle any time a user tries to access some kind of resource that they are not authorized to access.
So in other words long story short let's create another custom air to handle this response or the case
in which a user is trying to access a route that they do not have access to inside my ears directory
I'm gonna make a new file called not authorized air dot T.S. so we're going to create yet another custom
air inside of your remember to do so we will import custom air at the top from customer we will then
create an export a class we're gonna call it not authorized air and it's going to be extending custom
air once again typescript is going to guide us and how to implement this.
So we need to implement that serialize Eris method Andy status code method as well so for the status
code we probably want a status good for one which in HDP parlance means a you're not authorized or you
are forbidden from accessing this we can then put on the method of serialize errors
and recall that if we mouse over that thing we will be told that we have to return an array of objects
for each object has a message and possibly a field.
So in our case we'll just send back a hard coded message something says hey you are not authorized so
I will return an array of objects that has a message property and I'll put inside they're not authorized.
Last thing we're gonna put inside of here is a constructor once again.
Remember we are just putting in the constructor to set up that set credit type of thing that is required
because we are ultimately extending a built in class.
Don't put in a constructor I will call super l do an object set Prato type of this and not authorized
air dot prototype.
You'll notice that we have an air around our super called right here.
That is because the parent constructor of customer expects to be called with some message or some kind
of string describing exactly what went wrong.
So we can just use the same string we use down here we can put in something like not authorized
okay.
So there's our customer.
So let's say this file will then go backwards the require of middleware and again rather than throwing
or trying to send back some manual response right here we can instead just throw that error that we
had just created in our error handling middleware.
We'll take care of everything from there.
So at the top we will import not authorized air rom errors
and then rather than returning right there we can throw a new not authorized air now assuming that the
user is logged in if they are logged in and they get past this if statement we want to allow the user
to continue on to the next middleware or possibly our actual route handling function.
So if they get past that statement we'll just call the next function and attribute
all right let's say this.
Now we don't have any root handlers inside of this app that need to have some kind of require off middleware
on them.
So we're going to a very temporarily apply it to the current user middle or something the current user
route handler.
So we're going to temporarily make sure that you must be logged in in order to access current user.
So I'm gonna go and find that current user route handler at the very top.
I will import the middleware we just created so require off from middle wears require off and then remember
our big assumption here is that we are always going to run require off right after using current user
or I should say right after.
But at some point after current user so I will put in require like so.
All right so let's say this.
Now we could go back over to postmen and test it out now.
At present I am signed in inside a postman.
So if I send this request off to get current user right now it should still succeed.
Yep definitely does.
But if I go over to that third tab where I can log out so I'll send that in.
So now I'm no longer signed into the application.
If I now try to print out current user again I should get an airbag something and says Sorry you can't
access this route because you are not logged in.
So I will send this.
And sure enough there we go.
So I get back an error with the message of not authorised.
All right.
Fantastic.
So we've now got these two utility middleware put together that we're probably going to need to use
at some point time even if we don't really need them inside of our service just yet.
Now back inside of current user the root handler a current user I am going to delete the require off
middleware right there.
Again we were just doing a very quick test and I will delete require off right there and you know we're
not using JWT inside of here anymore so delete that as well.
All right that's it.
Well we've got those two utility middleware put together and I think overall our entire auto service
is now in a pretty good state.
So let's take a quick pause right here and figure out exactly what we need to do next.