1
00:00:00,520 --> 00:00:06,240
Unless section we finished up our request handler that charges the user updates the number of credits

2
00:00:06,240 --> 00:00:10,430
that they have and then sends a user model back to whoever made the request.

3
00:00:10,440 --> 00:00:15,160
So we're now ready to test this out inside the browser and make sure that it's working the way we expect.

4
00:00:15,180 --> 00:00:17,060
So I'll change back over to my browser.

5
00:00:17,160 --> 00:00:19,250
We are going to eventually add some credits.

6
00:00:19,260 --> 00:00:24,480
But before we do we need to make sure that we have some means or some way of ensuring that yes we did

7
00:00:24,480 --> 00:00:26,620
actually add some credits to this user.

8
00:00:26,880 --> 00:00:32,000
So at present we are sending the user back inside the response to the request.

9
00:00:32,010 --> 00:00:36,750
So I think that we should open up our request log inside of our chrome console.

10
00:00:36,810 --> 00:00:44,580
So pull up my dev tools or flip on over to network right here on sorted by X-C requests and now when

11
00:00:44,580 --> 00:00:50,610
we go through the adding credits phase and we make that request to API slash Strype we should see inside

12
00:00:50,610 --> 00:00:57,040
the response that comes back the updated user model that specifies how many credits a user has available.

13
00:00:57,330 --> 00:00:59,340
So let's give this a shot.

14
00:00:59,340 --> 00:01:01,290
Click on add credits at the top.

15
00:01:01,500 --> 00:01:09,970
We put in our fake info again we'll do our 3:56 to number and then we'll pay our $5.

16
00:01:10,380 --> 00:01:16,020
Now when we get the token back from Strype we make our requests to APRC less Strype it looks like the

17
00:01:16,020 --> 00:01:19,380
request was successful because I see a status of 200 here.

18
00:01:19,620 --> 00:01:25,350
If I click on the request itself and then select the preview tab right here you can see the response

19
00:01:25,350 --> 00:01:31,380
that was sent back to us from the API and so on here you can see very plainly we now have 5 credits

20
00:01:31,440 --> 00:01:32,770
assigned to this user.

21
00:01:32,970 --> 00:01:34,920
So presumably this started off with zero.

22
00:01:34,950 --> 00:01:40,680
We just added 5 and now the user has in total five credits with which they can use to send out surveys

23
00:01:40,740 --> 00:01:42,370
inside of our application.

24
00:01:42,720 --> 00:01:43,950
So that looks pretty good.

25
00:01:43,950 --> 00:01:47,260
It looks like billing is certainly working inside of our app.

26
00:01:47,290 --> 00:01:51,270
However there is one quick thing I want to point out to you.

27
00:01:51,270 --> 00:01:52,230
One quick thing.

28
00:01:52,470 --> 00:01:58,550
Kind of a little bit of gap in logic inside of our route handler right here at present.

29
00:01:58,680 --> 00:02:05,310
Every single time a request comes in we are always looking at that request object and assign assuming

30
00:02:05,400 --> 00:02:08,040
that the user property exists there.

31
00:02:08,100 --> 00:02:13,840
Remember that red user gets assigned by passport remember whenever the request comes in.

32
00:02:14,010 --> 00:02:20,010
Passport looks at the cookie and says OK is there a user ID here if there is it assigns the user model

33
00:02:20,040 --> 00:02:21,750
to the request.

34
00:02:21,750 --> 00:02:28,910
However what would happen if someone made a request to this point when they were not logged in.

35
00:02:29,100 --> 00:02:34,320
If someone made a request to API slash stripe right here when they were not logged in for just whatever

36
00:02:34,320 --> 00:02:42,220
crazy reason when our server got to this line of code right here recked user user would be undefined.

37
00:02:42,240 --> 00:02:47,310
And so our server would immediately throw an error message and say hey you're not logged in like I don't

38
00:02:47,310 --> 00:02:48,190
know who you are.

39
00:02:48,210 --> 00:02:55,170
I don't know who to assign credit to and this is even assuming that we got a token inside of the requests

40
00:02:55,170 --> 00:02:55,930
body.

41
00:02:56,130 --> 00:03:03,510
And so the way in which our handlers set up right now it really is assuming that a user is logged in

42
00:03:03,570 --> 00:03:06,240
whenever they make a request to a pizza last night.

43
00:03:06,480 --> 00:03:11,910
But there's really nothing about our handler that kind of asserts that fact and says hey you have to

44
00:03:11,910 --> 00:03:14,570
be logged in in order to add credit to your account.

45
00:03:14,640 --> 00:03:18,750
Like what does it even mean to add credit to an account when you don't have an account at all.

46
00:03:19,110 --> 00:03:24,000
So I think that we need to do a little bit of work inside of this rogue handler right here and make

47
00:03:24,000 --> 00:03:30,480
sure that a user is logged in before we attempt to add any credit or attempt to Bill any credit card

48
00:03:30,480 --> 00:03:32,340
or anything like that.

49
00:03:32,430 --> 00:03:36,450
Now making sure that the user is logged in is pretty straightforward.

50
00:03:36,480 --> 00:03:37,950
It's not the worst thing in the world.

51
00:03:38,070 --> 00:03:43,530
At the very top of this rough handler we're going to add just a little bit of code and say Hey are you

52
00:03:43,530 --> 00:03:46,830
logged in because if you're not you need to be logged in.

53
00:03:46,920 --> 00:03:49,800
Now we're going to take kind of a naive approach to this right now.

54
00:03:49,800 --> 00:03:54,420
We're going to put together an implementation inside the TSRA handler that is definitely going to work

55
00:03:54,420 --> 00:03:55,320
out correctly.

56
00:03:55,590 --> 00:04:01,950
And then Emily will talk a little bit about why or why not this might not work throughout our entire

57
00:04:01,950 --> 00:04:02,790
application.

58
00:04:02,790 --> 00:04:06,930
So we'll take the naive approach right now and we'll talk about some ways to improve this little snippet

59
00:04:06,930 --> 00:04:07,870
of code.

60
00:04:08,340 --> 00:04:08,580
OK.

61
00:04:08,580 --> 00:04:14,670
So at the very top the request handler we're going to a very simple a very straightforward check if

62
00:04:15,030 --> 00:04:23,310
there is not a user signed in some other words if passport did not find a user that was referenced inside

63
00:04:23,310 --> 00:04:27,990
the cookie including the request then we want to just end this entire request early.

64
00:04:27,990 --> 00:04:32,520
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.

65
00:04:32,520 --> 00:04:37,850
Nothing else just right and the request early and send back some sort of message.

66
00:04:37,890 --> 00:04:45,780
So if no user exists we will immediately return from the request handler say rez will set a status on

67
00:04:45,780 --> 00:04:48,620
the request status of 401.

68
00:04:48,660 --> 00:04:51,230
Which means unauthorized or forbidden.

69
00:04:51,270 --> 00:04:54,300
You have to be logged in to make a request as employment.

70
00:04:54,300 --> 00:05:00,690
So this sets the HTP status code of the request and then to send back some type of actual error message

71
00:05:00,690 --> 00:05:04,590
that the user can reference or that we as engineers could reference.

72
00:05:04,590 --> 00:05:09,300
We will also send back a little error message of error.

73
00:05:09,990 --> 00:05:19,980
You must log in like so get so this is the first time we've seen this type of syntax right here on the

74
00:05:19,980 --> 00:05:25,470
response object we first set the status of the response and then we send back some actual data with

75
00:05:25,470 --> 00:05:26,120
it.

76
00:05:26,130 --> 00:05:30,300
So if this ever shows up in the browser or if someone ever encounters this message right here it will

77
00:05:30,300 --> 00:05:34,660
say very plainly Hey you are forbidden from accessing this resource.

78
00:05:34,680 --> 00:05:39,080
And then we send back the message hey you must log in in order to do this.

79
00:05:39,590 --> 00:05:39,970
OK.

80
00:05:39,990 --> 00:05:42,140
So this definitely works right here.

81
00:05:42,160 --> 00:05:43,010
This definitely works.

82
00:05:43,020 --> 00:05:47,620
What we see right here it absolutely positively works for this route handler.

83
00:05:47,940 --> 00:05:54,210
But I want to point out the fact here that I mean without a doubt there will probably be other routes

84
00:05:54,240 --> 00:05:59,700
inside of our application that we also want to secure with this type of check as well.

85
00:05:59,970 --> 00:06:05,850
So there might be many locations inside of this project where we want to make sure that user is in fact

86
00:06:06,150 --> 00:06:06,840
logged in.

87
00:06:06,840 --> 00:06:11,190
Before we start to execute any actual logic like this.

88
00:06:11,190 --> 00:06:16,470
So I don't want to have to really rewrite this logic all the time right here at the top of every single

89
00:06:16,470 --> 00:06:18,390
one of those request handlers.

90
00:06:18,390 --> 00:06:19,890
So let's take a quick break.

91
00:06:19,890 --> 00:06:25,290
When we come back in the next section we're going to figure out a clever way to kind of pull this logic

92
00:06:25,290 --> 00:06:31,290
right here into a single location that will allow us to kind of dry up our code over time and make sure

93
00:06:31,290 --> 00:06:35,220
that we don't have to be repeating this little check every single time.

94
00:06:35,310 --> 00:06:38,450
We have a handler where we want to ensure that the user is logged in.

95
00:06:38,760 --> 00:06:40,190
So just take a quick break.

96
00:06:40,200 --> 00:06:44,210
We'll come back and we'll figure out how to kind of generalize this logic right here.

97
00:06:44,370 --> 00:06:45,990
So I'll see you in just a minute.