1
00:00:00,630 --> 00:00:05,850
In the last section we added in a little bit of logic to ensure that the user is authenticated before

2
00:00:05,850 --> 00:00:11,600
we allow the request to continue into the body of the request handler at the very end of the video.

3
00:00:11,610 --> 00:00:17,250
We said however that there might be many routes inside of our application where we require authentication

4
00:00:17,250 --> 00:00:18,010
like this.

5
00:00:18,060 --> 00:00:23,040
And so we don't want to have to be rewriting the same statement all over the time all over our code

6
00:00:23,040 --> 00:00:23,780
base.

7
00:00:23,790 --> 00:00:28,650
So in this video we're going to kind of generalize the logic right here and pull this logic out to a

8
00:00:28,650 --> 00:00:34,570
single location that we can then make use of again in several other locations inside of our project.

9
00:00:34,860 --> 00:00:41,520
So we get started with this actual brief factor I want to remind you about a little feature in the world

10
00:00:41,520 --> 00:00:44,460
of express that we spoke about briefly earlier.

11
00:00:44,460 --> 00:00:50,250
Inside this course and also in like just one or two videos ago remember that when a request comes in

12
00:00:50,250 --> 00:00:56,490
from the user's browser it gets sent to our express application there can optionally be some number

13
00:00:56,490 --> 00:00:59,270
of middleware wired up to our application.

14
00:00:59,490 --> 00:01:06,420
Those middleware are used to inspect an incoming request and modify it or change it if it so wishes

15
00:01:07,290 --> 00:01:11,820
the request is then taken and sent off to any different route handler that we might have inside of our

16
00:01:11,820 --> 00:01:12,830
app.

17
00:01:12,870 --> 00:01:18,600
Now thinking about this middleware thing in the context of our problem remember it's some function that

18
00:01:18,600 --> 00:01:23,360
takes the incoming request and kind of messes around with it just a little bit before the request is

19
00:01:23,370 --> 00:01:24,350
sent on.

20
00:01:24,690 --> 00:01:28,050
So thinking about our problem here we've got all requests coming in.

21
00:01:28,200 --> 00:01:34,050
It goes to the Express application the Express application sends the requests to the passport middleware

22
00:01:34,170 --> 00:01:40,050
where the current user is assigned to the request body or to the actual request object and then immediately

23
00:01:40,050 --> 00:01:43,560
after that is when we want to make sure that our user is logged in.

24
00:01:43,770 --> 00:01:48,680
But in this case unlike some of the other middleware that we've seen that we previously wired up inside

25
00:01:48,690 --> 00:01:51,600
of our index not just file.

26
00:01:51,820 --> 00:01:59,520
So like these for middleware right here unlike all of these we only want to run this particular check

27
00:01:59,650 --> 00:02:05,730
the Slyke little check to make sure that a user is logged in on some very particular route handlers.

28
00:02:05,790 --> 00:02:12,100
So we do want to check all over the place we want to just do this in some very particular route handlers.

29
00:02:12,450 --> 00:02:18,000
So here's what we're going to do and this video we're going to create a new middleware that we will

30
00:02:18,000 --> 00:02:22,740
use to make sure that a user is actually logged into our application.

31
00:02:22,740 --> 00:02:29,280
We will then make use of that middleware with only some very particular request handlers specifically

32
00:02:29,280 --> 00:02:34,770
the ones that we want to have ensure that a user is logged in before they actually access that given

33
00:02:34,860 --> 00:02:36,280
request handler.

34
00:02:36,330 --> 00:02:40,590
So we're not going to use this middleware that we are going to author in the same way that we did all

35
00:02:40,590 --> 00:02:45,900
these others these other middleware as were being used for every single request that comes in to the

36
00:02:45,900 --> 00:02:46,980
application.

37
00:02:46,980 --> 00:02:51,000
We want to apply ours to just some very particular routes.

38
00:02:51,610 --> 00:02:51,950
OK.

39
00:02:51,960 --> 00:02:55,680
So then mind let's give this a shot.

40
00:02:55,680 --> 00:02:59,450
Now in our application we might end up having many different middleware.

41
00:02:59,610 --> 00:03:04,980
So I'm going to decide to kind of centralize all of my middleware so that I might create that are accustomed

42
00:03:04,980 --> 00:03:13,720
to my project inside of a single directory that I'm going to call middleware is inside of that folder.

43
00:03:13,720 --> 00:03:17,200
I'm going to make a new file called require log in.

44
00:03:17,350 --> 00:03:18,580
Yes.

45
00:03:18,580 --> 00:03:24,010
Now remember our naming convention throughout our project if we export a single function or just kind

46
00:03:24,010 --> 00:03:26,150
of like a little piece of code a little snippet.

47
00:03:26,320 --> 00:03:28,340
We use a lower case r.

48
00:03:28,390 --> 00:03:34,330
If we are exporting a class of any type like a Component class or a model class or whatever it might

49
00:03:34,330 --> 00:03:37,410
be that's when we start to use a capital letter.

50
00:03:37,750 --> 00:03:42,430
So we have a lower case are here which indicates that we are going to be exporting a function and that

51
00:03:42,430 --> 00:03:44,250
function will be the middleware.

52
00:03:44,730 --> 00:03:45,000
OK.

53
00:03:45,010 --> 00:03:47,350
So let's see how we do this at the very top.

54
00:03:47,350 --> 00:03:51,370
We're going to define and immediately export an arrow function.

55
00:03:51,370 --> 00:03:59,350
So we'll say module exports place our parentheses like so now like I told you earlier and middleware

56
00:03:59,350 --> 00:04:05,410
is a function that takes the incoming request and has the ability to kind of modify it inside of the

57
00:04:05,410 --> 00:04:08,020
middle where body inside of this function.

58
00:04:08,020 --> 00:04:12,760
So we're going to take in three different arguments that kind of assist in that process.

59
00:04:12,790 --> 00:04:17,230
We're going to take an argument called rech which is the same request object that we've been working

60
00:04:17,230 --> 00:04:18,610
with all along.

61
00:04:18,690 --> 00:04:23,650
We'll take in the Reds argument which is the same as the response object that we've been working with

62
00:04:23,650 --> 00:04:24,700
all along.

63
00:04:24,700 --> 00:04:31,390
And then we've got one new argument that we're going to put on here called next next right here is a

64
00:04:31,390 --> 00:04:36,640
function that we call when our middleware is complete or like all finished running.

65
00:04:36,820 --> 00:04:41,890
The next middleware you can think of is kind of being like that done callback that we saw inside of

66
00:04:41,890 --> 00:04:43,990
some of our passport code.

67
00:04:43,990 --> 00:04:49,750
The reason that we're calling it next in this case is that our application remember it might have many

68
00:04:49,750 --> 00:04:52,030
different middleware inside of it.

69
00:04:52,030 --> 00:04:57,310
And so the next key or the next function is name the way it is to kind of indicate when you call this

70
00:04:57,310 --> 00:05:02,020
function it's going to pass the request off to the next middleware in the chain.

71
00:05:02,020 --> 00:05:08,170
So in other words after middleware number one right here finishes running it will call next that passes

72
00:05:08,170 --> 00:05:12,030
the request on to the next middleware in the chain.

73
00:05:12,840 --> 00:05:13,430
OK.

74
00:05:13,720 --> 00:05:18,090
So for us the logic that we have to put in here is pretty darn straightforward.

75
00:05:18,130 --> 00:05:22,000
Again we just want to check and make sure that the user is signed in.

76
00:05:22,360 --> 00:05:28,690
So just like we did inside of our handler will say if there is not a user that has been assigned by

77
00:05:28,690 --> 00:05:35,850
passport already then immediately return with a response that has a status of 401.

78
00:05:35,890 --> 00:05:46,890
Which means forbidden and will send back a message that says air you must log in like so.

79
00:05:47,710 --> 00:05:48,020
OK.

80
00:05:48,030 --> 00:05:54,090
So this right here very clearly kind of terminates the incoming request it says hey something is wrong

81
00:05:54,090 --> 00:05:54,550
with this.

82
00:05:54,570 --> 00:05:58,540
We want to bail out of your early so returned from this middleware.

83
00:05:58,740 --> 00:06:03,500
Take the response object and send a response back right now.

84
00:06:03,570 --> 00:06:08,560
Now remember that we just spoke about how at the very end of every middle where we have to call next.

85
00:06:08,700 --> 00:06:14,610
Well that's only if we actually truly do want to go to the next middle where if something happens in

86
00:06:14,610 --> 00:06:19,400
middle we're number one that is kind of indicative of some pending error or something like that.

87
00:06:19,410 --> 00:06:22,330
Like exactly our case a users not logged in.

88
00:06:22,380 --> 00:06:27,570
If we if we let this request go on any further the server might crash which would obviously be very

89
00:06:27,570 --> 00:06:28,520
bad.

90
00:06:28,530 --> 00:06:33,180
So what we want to do is say hey there's something wrong with this request something is going very wrong

91
00:06:33,180 --> 00:06:33,640
here.

92
00:06:33,720 --> 00:06:36,090
Just stop the entire middleware chain.

93
00:06:36,090 --> 00:06:41,450
Do not go to the request handler stop the request right now and immediately send back response.

94
00:06:41,520 --> 00:06:45,690
And so that is exactly what we are doing right here.

95
00:06:45,700 --> 00:06:47,690
However if the user is logged in.

96
00:06:47,730 --> 00:06:53,400
So if the user does exist if passport has found a user inside the request that is the case in which

97
00:06:53,400 --> 00:06:58,810
we want to allow this this request to continue onto the next middleware in our chain or potentially

98
00:06:58,810 --> 00:07:01,290
the actual route handler itself.

99
00:07:01,290 --> 00:07:05,220
So at the very bottom we'll call next like so.

100
00:07:05,520 --> 00:07:10,860
So this essentially says if there is no user something is wrong with the request immediately return

101
00:07:11,190 --> 00:07:13,310
and send a response back to the user.

102
00:07:13,380 --> 00:07:15,290
Otherwise hey everything looks good.

103
00:07:15,300 --> 00:07:19,620
Let's let this user continue on to the actual request handler.

104
00:07:20,250 --> 00:07:20,580
OK.

105
00:07:20,610 --> 00:07:22,460
Now onto the very last step here.

106
00:07:22,500 --> 00:07:24,500
We have completed our middleware.

107
00:07:24,540 --> 00:07:30,210
We're now going to wire it up to our very particular route that we want to apply it to.

108
00:07:30,210 --> 00:07:36,930
So the way in which we wrote our middleware right here we could wire up to our express app object inside

109
00:07:36,930 --> 00:07:40,530
of our index not just file where we wired up all the others.

110
00:07:40,740 --> 00:07:47,490
So the where we just created it could very easily be used inside of this with our app object to use

111
00:07:47,490 --> 00:07:49,590
the app don't use call right here.

112
00:07:49,590 --> 00:07:55,360
However we have said that only on some routes should a user actually be logged in.

113
00:07:55,890 --> 00:07:59,770
So for us we're not going to say that every route has to go through our middleware.

114
00:07:59,790 --> 00:08:07,260
We're going to say only the API slash stripe route does so only this one is going to actually require

115
00:08:07,650 --> 00:08:10,060
a user to be authenticated.

116
00:08:10,470 --> 00:08:16,110
So to use that middleware inside this request handler will first require in the middle where at the

117
00:08:16,110 --> 00:08:28,860
top will say Konst require log in is coming from up 1 directory middleware is required log in and then

118
00:08:28,860 --> 00:08:34,890
to specify that we want specifically this request handler right here to run this middleware before it

119
00:08:34,890 --> 00:08:41,450
goes to the request body right or to the actual request handler logic itself we will add in required

120
00:08:41,490 --> 00:08:45,130
log in as a second argument to the handler.

121
00:08:45,140 --> 00:08:53,220
So right after API slash stripe will say require log in like so and then we put down the actual request

122
00:08:53,220 --> 00:08:55,910
handling function as the third argument.

123
00:08:56,420 --> 00:08:56,680
OK.

124
00:08:56,700 --> 00:08:58,220
So quick couple of things in here.

125
00:08:58,220 --> 00:09:01,560
You'll notice that I did not invoke require log in.

126
00:09:01,560 --> 00:09:07,350
It is a function yes but we're not calling it like this and we're not calling it right now because we

127
00:09:07,350 --> 00:09:10,790
don't want to require log in or to run this middleware.

128
00:09:10,860 --> 00:09:16,680
The instant express loads up or we execute inside of our terminal and run this code for the very first

129
00:09:16,680 --> 00:09:22,350
time what we're doing right here is we're saying hey express any time someone makes a post request to

130
00:09:22,350 --> 00:09:23,380
this route.

131
00:09:23,540 --> 00:09:28,650
Here's a reference to a function to run whenever a request comes in.

132
00:09:28,650 --> 00:09:34,590
So Express takes the reference to this function and express will call it internally or call it itself

133
00:09:34,890 --> 00:09:38,610
whenever some request comes into the application.

134
00:09:38,610 --> 00:09:43,620
Now the other thing I want to say is that I did kind of I said very clearly like oh yeah we want this

135
00:09:43,620 --> 00:09:47,900
to be the second argument and we want this on to be the third argument right here.

136
00:09:47,920 --> 00:09:55,620
Well to be honest all these Raut handlers like appetite get amped up post or whatever take an arbitrary

137
00:09:55,620 --> 00:10:01,230
number of arguments so we could pass in as many middleware is here as we want.

138
00:10:01,290 --> 00:10:07,260
The only requirement of is of express is that eventually one of the functions inside this list right

139
00:10:07,260 --> 00:10:13,710
here like be it require log in be it some other middleware we put in or be at this actual function that

140
00:10:13,710 --> 00:10:15,370
we defined ourselves right here.

141
00:10:15,510 --> 00:10:22,140
Eventually one of these functions has to process the request and eventually send back in response to

142
00:10:22,140 --> 00:10:22,980
the user.

143
00:10:23,040 --> 00:10:29,070
Thats the only requirement of Express doesn't care how many little functions you toss in here just eventually

144
00:10:29,160 --> 00:10:34,890
one of them has to actually say OK heres the actual response here you go send it off to whoever made

145
00:10:34,890 --> 00:10:35,600
the request.

146
00:10:35,670 --> 00:10:37,430
That's the only requirement.

147
00:10:38,000 --> 00:10:38,720
OK.

148
00:10:39,330 --> 00:10:42,290
So that's pretty much it for putting our middleware together.

149
00:10:42,480 --> 00:10:48,270
Now the very last thing we're going to do inside the top of this request handler we no longer have to

150
00:10:48,270 --> 00:10:52,050
manually check this with the if statement that we just put together.

151
00:10:52,110 --> 00:10:55,780
So I'll take that out and we are left with just this like so.

152
00:10:56,140 --> 00:11:02,640
So now it's very easy for us to secure any route inside of our application with this required log in

153
00:11:02,640 --> 00:11:03,310
Middleware.

154
00:11:03,330 --> 00:11:04,710
We just have to require it in.

155
00:11:04,860 --> 00:11:11,190
And then before we actually run any logic on the incoming request we say hey take the request throw

156
00:11:11,190 --> 00:11:12,480
it into this middleware right here.

157
00:11:12,510 --> 00:11:14,790
Make sure the user is actually signed in.

158
00:11:14,790 --> 00:11:16,210
And that's pretty much it.

159
00:11:16,770 --> 00:11:17,100
OK.

160
00:11:17,130 --> 00:11:22,170
So I think that our billing stuff at least some server side is all pretty much wrapped up.

161
00:11:22,200 --> 00:11:28,290
So I think the very last thing we have to do is to make sure that back inside of our application the

162
00:11:28,290 --> 00:11:32,670
number of credits that the user has is somehow visible inside the head.

163
00:11:32,820 --> 00:11:37,170
So let's flip back to the client in the next section and take care of that last task.

164
00:11:37,230 --> 00:11:38,950
So I'll see you in just a minute.