Onto our next test.
So we want to make sure that we can only access this root handler if the user is actually signed in.
Let's first just create a test for this and we'll worry about the actual implementation.
So I'm going to put in a body to this thing I'm going to try to make a request over
to my app.
I again want to make a POST request to API tickets.
And again I'm going to send in an empty object so in the scenario right here we are not authenticated
in any way.
We are not sending this request with any kind of status code or some kind of cookie Jason web token
or anything like that.
So if we just send this right here this is going to stimulate us making a request to the threat handler
as if we were not signed in so we need to now look at that response and make sure that it has a status
code that is somehow telling us that we are not correctly authenticated.
That means we're going to have to get a quick reminder on what happens when we make a request that we
are essentially not authenticated to make it's going to go back over to my common library.
Inside there I'll find the heirs directory and you might recall that a while ago back when we were working
on the off service we put together a custom air called not authorized air.
This was the air that we would throw whenever a user tried to make a request or a root handler that
they were not allowed to make request to so if we tried to make a request to a handler if they were
not authorized to access we should be getting back a status code for a one to back inside this test.
We can either take a look at the response and write out something very similar to what we wrote out
up here.
So in other words we could say expect response status to equal for a one because in this case we want
to make sure that are not authenticated requests gets rejected or alternatively we could just chain
on an expect statement to the request itself of for a one if we do that we do not need to get access
to the response itself or write out the separate expectation.
Let's save this and go back over to my terminal again and I'll see that that second test is failing
so we expected or we want to see that we got a four a one but we actually got through to our root handler
with a status code up to 100.
Coming back to us that means that right now we do not have any idea of authentication being tied to
this drought handler.
So we need to now go into our implementation.
We need to make sure we add something in to say hey at the user is not authenticated.
Get them out of here.
So how are we gonna do that.
Well once again you might recall that when we were working on our auth service we kind of thought ahead
and we realized that at some point time we've probably need some middleware to detect whether or not
the user was actually authenticated.
And to that end we put together two different middleware as we put together a middleware called current
user.
So I'm inside of my common module right now.
Here's the current user middleware.
The whole goal of this thing was to take a look at the incoming requests session property and see if
there's a Jason web token there.
If there wasn't a token we just called next.
Otherwise if there was we attempted to decode the token and then set it on the current user property
with the current user middleware it was just about defining that wrecked current user property.
That was it.
That's all we cared about with this thing the other middleware that we put together was required.
OK so gonna open that up really quick require off middleware.
It's going to take a look at that current user property and if it is not defined we're gonna throw a
not authorized air so all we really have to do to implement some level of authentication protection
around our right handler is wire up both the current user middleware and the require off middleware
as well as pretty much it.
So where are we going to actually wire these things up.
Well every single request that comes into our application if the user is authenticated or has a J somewhere
token we probably want to do that.
Current user lookup so inside of our app dot TSA file we're going to import that current user middleware
inside of here and wired up to our app so that every single incoming request is going to have that look
up and see whether or not the user is authenticated but if the user is not authenticated we don't necessarily
want to immediately reject them.
Instead we only want to reject requests that are coming into a very specific route handlers.
So for example if someone is trying to look up a list of all tickets or look up a very specific ticket
we probably don't want to make someone be authenticated for that.
So I don't really want to require authentication on these two root handlers but in order to make a post
to create a ticket or to update a ticket I probably do so only some route handlers need to have that
require auth middleware wired up.
So long story short here's what we're going to do inside of app.
Yes I'm going to find my common module import and I'll add on the current user middleware I'll then
connect that to my application down here apt use different user make sure you add that middleware after
Cookie session cookie session has to run first.
So can take a look at the cookie and set the record session property.
If we don't do that then whenever current user runs it will be running too soon and wrecked out session
will not be set so now if the user is authenticated that will set the record current user property.
And now we can go over to our actual root handler so inside of roots new dot.
Yes.
And this is where we will apply some actual authentication protection and make sure that the user is
authenticated.
So at the very top this is where we will import the require auth middleware from my common module and
I will apply that as a middleware inside my root handler the require off like so.
Let's save that way back over.
And now that test is passing
go now I just kind of realized we should probably write out a test that kind of checks for the opposite.
So if we want to write our test to make sure this thing can only be used if the user is signed in we
probably should have a test that says if the user is signed in we should not return a status code of
400.
I think that makes it a little bit of sense because right now we could be signed in and who knows maybe
at the request handler still isn't working correctly.
So we should probably just write out a test to make sure that's working as expected.
It's gonna put in another test right here and I'll say the user.
How about returns a status other than for one if the user is signed in
then to write out this test we can do something very similar to what we did back up here.
So in this case we need to make sure that the status code is not equal to a 4 1 Don't let's write out
a test for that.
So we'll do a concert response is a wait request to app I'm gonna make a post to API tickets I will
send an empty object and we'll do it and expect response not status not two equal or one.
All right.
Now if I put back over I will see an error around that test it looks like that new test is failing entirely.
The reason that is failing is because well we are still making a request right here that is not authenticated
in any way.
So we need to figure out some method or some methodology to make an authenticated request inside of
our test environment.
You might recall that we've put together our test suite back inside the service we had put together
inside of our setup dot t s file that global sign in function right here.
So I'm at the bottom of our setup dot t s file we put this thing together over here and unfortunately
this thing is only going to work correctly inside of our service.
This video is running a little bit long however.
So let's take a pause right here.
We come back in the next video I'm going to explain to you why this thing will only work in the out
service and then start to fix it up so we can use it over here inside of tickets.