Unless section we finished up our request handler that charges the user updates the number of credits
that they have and then sends a user model back to whoever made the request.
So we're now ready to test this out inside the browser and make sure that it's working the way we expect.
So I'll change back over to my browser.
We are going to eventually add some credits.
But before we do we need to make sure that we have some means or some way of ensuring that yes we did
actually add some credits to this user.
So at present we are sending the user back inside the response to the request.
So I think that we should open up our request log inside of our chrome console.
So pull up my dev tools or flip on over to network right here on sorted by X-C requests and now when
we go through the adding credits phase and we make that request to API slash Strype we should see inside
the response that comes back the updated user model that specifies how many credits a user has available.
So let's give this a shot.
Click on add credits at the top.
We put in our fake info again we'll do our 3:56 to number and then we'll pay our $5.
Now when we get the token back from Strype we make our requests to APRC less Strype it looks like the
request was successful because I see a status of 200 here.
If I click on the request itself and then select the preview tab right here you can see the response
that was sent back to us from the API and so on here you can see very plainly we now have 5 credits
assigned to this user.
So presumably this started off with zero.
We just added 5 and now the user has in total five credits with which they can use to send out surveys
inside of our application.
So that looks pretty good.
It looks like billing is certainly working inside of our app.
However there is one quick thing I want to point out to you.
One quick thing.
Kind of a little bit of gap in logic inside of our route handler right here at present.
Every single time a request comes in we are always looking at that request object and assign assuming
that the user property exists there.
Remember that red user gets assigned by passport remember whenever the request comes in.
Passport looks at the cookie and says OK is there a user ID here if there is it assigns the user model
to the request.
However what would happen if someone made a request to this point when they were not logged in.
If someone made a request to API slash stripe right here when they were not logged in for just whatever
crazy reason when our server got to this line of code right here recked user user would be undefined.
And so our server would immediately throw an error message and say hey you're not logged in like I don't
know who you are.
I don't know who to assign credit to and this is even assuming that we got a token inside of the requests
body.
And so the way in which our handlers set up right now it really is assuming that a user is logged in
whenever they make a request to a pizza last night.
But there's really nothing about our handler that kind of asserts that fact and says hey you have to
be logged in in order to add credit to your account.
Like what does it even mean to add credit to an account when you don't have an account at all.
So I think that we need to do a little bit of work inside of this rogue handler right here and make
sure that a user is logged in before we attempt to add any credit or attempt to Bill any credit card
or anything like that.
Now making sure that the user is logged in is pretty straightforward.
It's not the worst thing in the world.
At the very top of this rough handler we're going to add just a little bit of code and say Hey are you
logged in because if you're not you need to be logged in.
Now we're going to take kind of a naive approach to this right now.
We're going to put together an implementation inside the TSRA handler that is definitely going to work
out correctly.
And then Emily will talk a little bit about why or why not this might not work throughout our entire
application.
So we'll take the naive approach right now and we'll talk about some ways to improve this little snippet
of code.
OK.
So at the very top the request handler we're going to a very simple a very straightforward check if
there is not a user signed in some other words if passport did not find a user that was referenced inside
the cookie including the request then we want to just end this entire request early.
We want to say hey we're not going to try to make any charges we're not going to try to add any credits.
Nothing else just right and the request early and send back some sort of message.
So if no user exists we will immediately return from the request handler say rez will set a status on
the request status of 401.
Which means unauthorized or forbidden.
You have to be logged in to make a request as employment.
So this sets the HTP status code of the request and then to send back some type of actual error message
that the user can reference or that we as engineers could reference.
We will also send back a little error message of error.
You must log in like so get so this is the first time we've seen this type of syntax right here on the
response object we first set the status of the response and then we send back some actual data with
it.
So if this ever shows up in the browser or if someone ever encounters this message right here it will
say very plainly Hey you are forbidden from accessing this resource.
And then we send back the message hey you must log in in order to do this.
OK.
So this definitely works right here.
This definitely works.
What we see right here it absolutely positively works for this route handler.
But I want to point out the fact here that I mean without a doubt there will probably be other routes
inside of our application that we also want to secure with this type of check as well.
So there might be many locations inside of this project where we want to make sure that user is in fact
logged in.
Before we start to execute any actual logic like this.
So I don't want to have to really rewrite this logic all the time right here at the top of every single
one of those request handlers.
So let's take a quick break.
When we come back in the next section we're going to figure out a clever way to kind of pull this logic
right here into a single location that will allow us to kind of dry up our code over time and make sure
that we don't have to be repeating this little check every single time.
We have a handler where we want to ensure that the user is logged in.
So just take a quick break.
We'll come back and we'll figure out how to kind of generalize this logic right here.
So I'll see you in just a minute.