1
00:00:00,000 --> 00:00:04,649
[MUSIC]

2
00:00:04,649 --> 00:00:08,820
In the previous lesson,
we learned about basic authentication.

3
00:00:08,820 --> 00:00:14,398
We saw that in basic authentication
the client will have to explicitly keep

4
00:00:14,398 --> 00:00:19,720
adding in the authorization field
containing the username and

5
00:00:19,720 --> 00:00:24,100
password for every request that
the client sends to the server side.

6
00:00:24,100 --> 00:00:27,750
Now that is perfectly fine for
simple authentication.

7
00:00:27,750 --> 00:00:33,520
Cookies are yet another mechanism that
is provided that enables your server

8
00:00:33,520 --> 00:00:38,700
to be able to expect the client to store
some information on the client side and

9
00:00:38,700 --> 00:00:43,370
include that information explicitly
in each outgoing request.

10
00:00:43,370 --> 00:00:47,360
So instead of including your
base-64 encoded username and

11
00:00:47,360 --> 00:00:53,710
password like we did in the basic
authentication, using cookies,

12
00:00:53,710 --> 00:00:58,130
your server may set up an explicit
piece of information on the client side

13
00:00:58,130 --> 00:01:02,520
which then will be included in each
outgoing request from the client side.

14
00:01:03,750 --> 00:01:08,740
Now expanding this further, if your server
wants to track information about your

15
00:01:08,740 --> 00:01:15,180
client, then the server may set up
explicitly a session tracking mechanism.

16
00:01:15,180 --> 00:01:20,720
Now, cookies are small and
can't store a lot of information in there,

17
00:01:20,720 --> 00:01:25,230
and this of course can not be
included in the outgoing request.

18
00:01:25,230 --> 00:01:28,010
Cookies can include some basic information

19
00:01:28,010 --> 00:01:31,850
in the header of the outgoing
request from the client.

20
00:01:31,850 --> 00:01:37,010
Now, if we want a lot more of
information to be tracked about a client

21
00:01:37,010 --> 00:01:42,420
on the server side, then
express-sessions enable us to do that.

22
00:01:42,420 --> 00:01:45,140
Let's study more about cookies and

23
00:01:45,140 --> 00:01:49,260
Express sessions in a bit more
detail in this lesson and

24
00:01:49,260 --> 00:01:54,380
also explore them further in
the exercises that follow this lecture.

25
00:01:56,640 --> 00:01:59,340
So what are HTTP cookies?

26
00:01:59,340 --> 00:02:04,070
HTTP cookies, as I mentioned,
are small piece of data that is sent

27
00:02:04,070 --> 00:02:07,610
from a web server and
is stored on the client side.

28
00:02:07,610 --> 00:02:12,030
Now, almost all browsers
have the ability to support

29
00:02:12,030 --> 00:02:16,850
the storing of cookies on the client side,
and automatically including them

30
00:02:16,850 --> 00:02:21,590
in the request when the request
is sent to a specific server.

31
00:02:21,590 --> 00:02:27,127
So each subsequent request from the client

32
00:02:27,127 --> 00:02:32,047
side will include a new header in there

33
00:02:32,047 --> 00:02:37,141
with the cookie in the request header.

34
00:02:37,141 --> 00:02:41,668
Now obviously, if you have seen the
popular press have gotten a bad reputation

35
00:02:41,668 --> 00:02:45,450
there, this is, of course,
not completely undeserved.

36
00:02:45,450 --> 00:02:52,880
But it is blown way out of proportion
than what is really the truth.

37
00:02:52,880 --> 00:02:57,760
So take anything that you read in
popular press about cookies and

38
00:02:57,760 --> 00:03:00,570
their bad reputation with a grain of salt.

39
00:03:00,570 --> 00:03:05,040
Cookies are very useful for
doing a lot of interesting things.

40
00:03:05,040 --> 00:03:09,880
And we can ensure that cookies
can have sufficient integrity

41
00:03:09,880 --> 00:03:15,070
built into them so that they cannot
be manipulated by anybody in between.

42
00:03:15,070 --> 00:03:21,640
Now how does this cookie setting
inclusion in the outgoing request work?

43
00:03:21,640 --> 00:03:25,060
When a client sends a request
to the server site,

44
00:03:25,060 --> 00:03:27,870
if the client is authenticated
on the server site.

45
00:03:27,870 --> 00:03:31,040
For example,
using the basic authentication,

46
00:03:31,040 --> 00:03:34,950
then the server may in return,
set up a cookie.

47
00:03:34,950 --> 00:03:39,120
Now, to set up a cookie on the client's
site, the server will include in

48
00:03:39,120 --> 00:03:44,090
the response message a header
with the sent cookie header and

49
00:03:44,090 --> 00:03:46,300
the actual cookie in the header.

50
00:03:46,300 --> 00:03:50,460
Now when the client receives the response
message from the server containing

51
00:03:50,460 --> 00:03:54,500
the Set-Cookie header, then it'll set
up the cookie on the client side.

52
00:03:54,500 --> 00:03:59,455
Such that each subsequent request
going from the client side will

53
00:03:59,455 --> 00:04:03,602
explicitly include a header
field called as cookie and

54
00:04:03,602 --> 00:04:06,846
actual header that contains as the value,

55
00:04:06,846 --> 00:04:13,200
the cookie information that has been sent
by the server in the response message.

56
00:04:13,200 --> 00:04:17,880
So each subsequent request message
will carry this cookie in the header.

57
00:04:17,880 --> 00:04:22,470
Thereby when the server receives this
request message it is able to examine

58
00:04:22,470 --> 00:04:28,490
the cookie and
surmise who this request is coming from.

59
00:04:28,490 --> 00:04:33,612
So it is able to recognize the client
by looking at the cookie information.

60
00:04:33,612 --> 00:04:38,543
So this is where cookies
prove very useful in

61
00:04:38,543 --> 00:04:44,019
being able to send
authorization information.

62
00:04:44,019 --> 00:04:48,050
So in serving including username and
password as part of the basic

63
00:04:48,050 --> 00:04:51,220
authentication header in
every ongoing request.

64
00:04:51,220 --> 00:04:55,120
The first time you authenticate yourself,
you send your username and password and

65
00:04:55,120 --> 00:04:57,140
the server sets up
the cookie on your side.

66
00:04:57,140 --> 00:05:02,070
Subsequently, you only need to include
the cookie in the outgoing request.

67
00:05:02,070 --> 00:05:06,789
Now cookies also can have an expiry
date associated with them.

68
00:05:06,789 --> 00:05:11,641
So thereby, at that point,
the cookie will be deemed as expired and

69
00:05:11,641 --> 00:05:13,440
will no longer be valid.

70
00:05:13,440 --> 00:05:16,940
So that is one way of
controlling the duration for

71
00:05:16,940 --> 00:05:20,340
which an authorization is valid.

72
00:05:20,340 --> 00:05:24,350
Coming to Express itself,
how does Express support cookies?

73
00:05:24,350 --> 00:05:28,980
Now as we understand,
Express uses a lot of middleware.

74
00:05:28,980 --> 00:05:34,100
This is where one of the middlewares
that comes in called the cookie parser

75
00:05:34,100 --> 00:05:37,092
comes to our app at eight.

76
00:05:37,092 --> 00:05:42,580
The cookie-parser allows the server to
set up a cookie in the response header.

77
00:05:42,580 --> 00:05:48,350
So this is done by using res.cookie and
the name and

78
00:05:48,350 --> 00:05:54,160
certain values and the options as
we will see in the exercise later.

79
00:05:54,160 --> 00:06:00,160
And so cookies, when they are sent from
the client-side, included in that request

80
00:06:00,160 --> 00:06:05,980
message are parsed on the Express
server side, using the cookie-parser.

81
00:06:05,980 --> 00:06:08,383
The cookie-parser middleware,

82
00:06:08,383 --> 00:06:13,400
which when installed will enable
you to parse the incoming cookies.

83
00:06:13,400 --> 00:06:17,280
And then these incoming
cookies will be added into

84
00:06:17,280 --> 00:06:22,260
the request as a header and
can be examined on the server side.

85
00:06:23,340 --> 00:06:26,580
Now in order to protect
the authenticity of the cookie,

86
00:06:26,580 --> 00:06:30,070
the cookies themselves can
be signed by the server.

87
00:06:30,070 --> 00:06:35,120
Now when the server signs a cookie,
the server uses a secret key,

88
00:06:35,120 --> 00:06:38,070
which is only known to the server side.

89
00:06:38,070 --> 00:06:42,510
Now if you know anything about
computer security and cryptography and

90
00:06:42,510 --> 00:06:47,210
encryption, then you understand
what signing and secret keys and

91
00:06:47,210 --> 00:06:49,290
public keys and all these things mean.

92
00:06:49,290 --> 00:06:53,990
If you don't, just suffice it
to say that a secret key is

93
00:06:53,990 --> 00:06:59,260
a specific string that only the server
knows and nobody else knows.

94
00:06:59,260 --> 00:07:05,505
So when a server encrypts a cookie, it
will use a secret key as a signature and

95
00:07:05,505 --> 00:07:11,081
create what is called as a key-hash
message authentication code.

96
00:07:11,081 --> 00:07:16,450
And includes this in that cookie that is
sent from the server to the client side.

97
00:07:16,450 --> 00:07:21,210
This HMAC that is created on
the server side can only be done

98
00:07:21,210 --> 00:07:24,540
by that specific server
knowing that secret key.

99
00:07:24,540 --> 00:07:27,950
Now, since the server is
a protected resource, so

100
00:07:27,950 --> 00:07:33,670
only the server will know the secret
key and so it is very easy to verify

101
00:07:33,670 --> 00:07:38,320
when a signed cookie is sent from
the client side to the server side.

102
00:07:38,320 --> 00:07:42,040
So when the signed cookie is sent from
the client side to the server side,

103
00:07:42,040 --> 00:07:44,540
the cookie will be set up
on the client side, and

104
00:07:44,540 --> 00:07:50,310
then all subsequent requests will include
this signed cookie in the client side.

105
00:07:50,310 --> 00:07:54,290
Now the cookie parser middleware that
we set up with our Express server

106
00:07:54,290 --> 00:07:56,630
already supports signed cookies.

107
00:07:56,630 --> 00:08:02,480
Now for this, in the cookie parser,
you will also supply the secret key as

108
00:08:02,480 --> 00:08:07,120
the parameter for the cookie parser when
you set up the cookie parser middleware.

109
00:08:07,120 --> 00:08:11,970
Thereby, all the cookies will be signed
appropriately and then sent out.

110
00:08:11,970 --> 00:08:17,240
And when the cookie is parsed on
the server side in the incoming

111
00:08:17,240 --> 00:08:22,660
request message, this will be added into
the request message as req.signedCookies.

112
00:08:22,660 --> 00:08:27,980
And then you can have a specific field
which you can check in the signed cookie.

113
00:08:27,980 --> 00:08:30,890
Cookies are very useful way of

114
00:08:30,890 --> 00:08:36,380
your client being able to send information
whereby your server recognizes the client.

115
00:08:36,380 --> 00:08:38,490
But of course, cookies have limitations.

116
00:08:38,490 --> 00:08:42,370
They are a fixed size, so
they cannot encode a lot of information

117
00:08:42,370 --> 00:08:47,090
about the client that their server
can retrieve from the cookie.

118
00:08:47,090 --> 00:08:50,710
The cookie is used to just
remind the server about

119
00:08:50,710 --> 00:08:53,750
which client is sending the request.

120
00:08:53,750 --> 00:08:58,311
Now if you want to have a more elaborate
mechanism to track information about

121
00:08:58,311 --> 00:09:02,889
a client, then on the server side you
can set up what are called as sessions.

122
00:09:02,889 --> 00:09:09,180
Now, sessions is a generic mechanism
that is available with any servers.

123
00:09:09,180 --> 00:09:11,850
In particular,
we'll look at Express itself and

124
00:09:11,850 --> 00:09:17,140
how Express supports session
management on the server side.

125
00:09:17,140 --> 00:09:22,930
The way it works is that the user
session is set up on the server side.

126
00:09:22,930 --> 00:09:27,430
So this session itself is
a combination of a cookie and

127
00:09:27,430 --> 00:09:32,270
a session ID, and
the server-side tracks information

128
00:09:32,270 --> 00:09:37,250
associated with that session ID,
or indexed by that session ID.

129
00:09:37,250 --> 00:09:40,500
The session information
itself can have any

130
00:09:40,500 --> 00:09:45,380
amount of information being tracked on the
server-side, and indexed by that cookie.

131
00:09:45,380 --> 00:09:50,910
So when a client sends a request over
the server, then from within the cookie

132
00:09:50,910 --> 00:09:56,130
the session ID is retrieved and that is
used as an index into the server side.

133
00:09:56,130 --> 00:09:56,964
For example,

134
00:09:56,964 --> 00:10:01,548
if you are using a server side database
that index will be the primary index into

135
00:10:01,548 --> 00:10:05,456
that particular server side
database which tracks the sessions.

136
00:10:05,456 --> 00:10:10,486
And thereby, additional information
about that session can be retrieved and

137
00:10:10,486 --> 00:10:13,761
used by your server in order
to make decisions on how

138
00:10:13,761 --> 00:10:17,380
it services the incoming client request.

139
00:10:17,380 --> 00:10:23,900
Now, by default, the sessions are stored
in memory on the server site.

140
00:10:23,900 --> 00:10:28,870
Now obviously, what this means is that
if your server is restarted, your memory

141
00:10:28,870 --> 00:10:33,260
will be cleared and so all the session
information will be gone completely.

142
00:10:33,260 --> 00:10:37,350
So instead, many servers will resort to

143
00:10:37,350 --> 00:10:42,010
using some form of permanent storage
where the session information is tracked.

144
00:10:42,010 --> 00:10:45,360
The permanent storage on the server
side could either be done

145
00:10:45,360 --> 00:10:47,500
through some kind of a file storage.

146
00:10:47,500 --> 00:10:53,460
Or even leverage the fact that you already
have a database on the server side and

147
00:10:53,460 --> 00:10:56,170
than store the session
information on the server side.

148
00:10:56,170 --> 00:10:59,590
For example, in your MongoDB itself.

149
00:10:59,590 --> 00:11:05,620
Now in the exercise that follows, we will
look at the use of a file storage for

150
00:11:05,620 --> 00:11:10,000
tracking session information
on the server side.

151
00:11:10,000 --> 00:11:14,450
Another aspect that you need to pay
attention to is the fact that if you

152
00:11:14,450 --> 00:11:19,540
are having a distributed server
implementation whereby multiple

153
00:11:19,540 --> 00:11:24,530
servers are acting as the server for
servicing the request.

154
00:11:24,530 --> 00:11:28,310
Then the distributor server should be
able to access the session information.

155
00:11:29,460 --> 00:11:32,470
Any one of this servers should be able
to access the session information.

156
00:11:32,470 --> 00:11:36,480
So you will need a distributor
sessions tool on the server side,

157
00:11:36,480 --> 00:11:40,780
to enable you to support
multiple replicated servers.

158
00:11:40,780 --> 00:11:45,450
Especially this is useful when we
are trying to ensure reliability

159
00:11:45,450 --> 00:11:46,870
of server operation.

160
00:11:47,960 --> 00:11:52,630
Now again, we won't get in too much of
details about those in this particular

161
00:11:52,630 --> 00:11:58,190
course, we will rely on understanding
basically how Express sessions work.

162
00:11:59,710 --> 00:12:02,080
Coming specifically to Express and

163
00:12:02,080 --> 00:12:06,080
how sessions management
is supported in Express.

164
00:12:06,080 --> 00:12:10,240
Express uses the express-session
middleware that supports

165
00:12:10,240 --> 00:12:14,760
the use of sessions in an Express server.

166
00:12:14,760 --> 00:12:18,110
Now you install
the express-sessions middleware.

167
00:12:18,110 --> 00:12:21,140
And in the exercise,
I'm going to use the FileStore

168
00:12:21,140 --> 00:12:24,470
as a way of permanently storing
the session information.

169
00:12:24,470 --> 00:12:30,440
And so we will also include
the session-file-store node module that

170
00:12:30,440 --> 00:12:37,305
enables us to use the files on the server
side to track the session information.

171
00:12:37,305 --> 00:12:41,120
We'll see the details in
the exercise that follows.

172
00:12:41,120 --> 00:12:46,247
And then once we do that your session
itself will be set up on with the new

173
00:12:46,247 --> 00:12:51,690
express server by declaring
the middleware here as session which takes

174
00:12:51,690 --> 00:12:57,390
a certain set of options
as a parameter here.

175
00:12:57,390 --> 00:13:02,200
The options include the name for the
session, so we'll give the session-id for

176
00:13:02,200 --> 00:13:03,500
the particular session.

177
00:13:03,500 --> 00:13:07,500
And then you'll also supply the secret,
a secret key that is used for

178
00:13:07,500 --> 00:13:12,460
encoding the signed cookie that'll
be sent to the client side.

179
00:13:12,460 --> 00:13:17,960
And then also additional information
including saveUninitialized, which

180
00:13:19,190 --> 00:13:24,625
will be a flag that is used and
also a resave flag that is used.

181
00:13:24,625 --> 00:13:28,760
We'll look at some of the details
of these options in the next slide.

182
00:13:28,760 --> 00:13:31,390
So all these options are specified here.

183
00:13:31,390 --> 00:13:36,945
And if you are FileStore as
the permanent storage for your sessions,

184
00:13:36,945 --> 00:13:42,130
then we will declare that also
in the session options there.

185
00:13:42,130 --> 00:13:47,450
So this is how we would set up
a session on the express server side

186
00:13:47,450 --> 00:13:49,510
using the express session Middleware.

187
00:13:49,510 --> 00:13:55,540
And the express-session Middleware,
when the client sends this information,

188
00:13:55,540 --> 00:13:58,980
this will be parsed on the server side and

189
00:13:58,980 --> 00:14:04,640
this will result in a property called a
session being added to the request object.

190
00:14:04,640 --> 00:14:09,460
So this session information will
be accessible in the request

191
00:14:09,460 --> 00:14:11,505
object as req.session.

192
00:14:11,505 --> 00:14:16,221
So the req.session will carry additional
information about that particular session

193
00:14:16,221 --> 00:14:18,325
for that particular client.

194
00:14:18,325 --> 00:14:22,979
Now once this session, incoming request
is parsed by the session middleware,

195
00:14:22,979 --> 00:14:28,957
the req.session property will
be added to the incoming

196
00:14:28,957 --> 00:14:33,447
request message object that express uses.

197
00:14:33,447 --> 00:14:40,097
So after the session is parsed, direct
session property will be available and

198
00:14:40,097 --> 00:14:46,165
we can examine that too to check
which client has sent this request.

199
00:14:46,165 --> 00:14:50,900
When they setup their session
object on server site,

200
00:14:50,900 --> 00:14:54,760
as we saw, we can setup various
options for that server site.

201
00:14:54,760 --> 00:14:59,790
The cookie, the options from the session
ID cookie and the default value for

202
00:14:59,790 --> 00:15:04,275
the cookie will be as shown here,
which is path: '/',

203
00:15:04,275 --> 00:15:07,700
httpOnly: true,
secure: false, maxAge: null.

204
00:15:07,700 --> 00:15:13,450
So this will be the default value of the
cookie that will be stored on the package

205
00:15:13,450 --> 00:15:17,680
and sent over to the client's
side as a signed cookie.

206
00:15:17,680 --> 00:15:23,306
And this would be included in every
incoming request from the client's site.

207
00:15:23,306 --> 00:15:28,080
Then the genid is the function
that generates the session ID.

208
00:15:28,080 --> 00:15:33,830
The default is to use the UUID of
the server itself as the general ID.

209
00:15:33,830 --> 00:15:38,720
Then the resave flag, if it is true,
forces a session to be saved back to

210
00:15:38,720 --> 00:15:41,470
the store even if it's not
modified by the request.

211
00:15:41,470 --> 00:15:44,230
Sometimes the incoming request may

212
00:15:45,580 --> 00:15:50,200
contain a need to modify the session
information on the server side.

213
00:15:50,200 --> 00:15:54,300
And so, if the session information is
modified, it'll have to be persistent.

214
00:15:54,300 --> 00:15:56,290
If not, then you don't need to persist it.

215
00:15:56,290 --> 00:16:00,454
But if you set the resave flag to true,
even if the session information on

216
00:16:00,454 --> 00:16:06,030
the server Is not modified by the incoming
client request, it'll still be resaved.

217
00:16:06,030 --> 00:16:09,980
The next flag that we looked
at was saveUninitialized.

218
00:16:09,980 --> 00:16:14,620
If this is true, it'll create a newly
created session without any modifications

219
00:16:14,620 --> 00:16:16,540
to be saved of the session store.

220
00:16:16,540 --> 00:16:21,164
Now we will set this to false by default,
which means that we only will

221
00:16:21,164 --> 00:16:25,008
track those sessions that
are authorized on the server.

222
00:16:25,008 --> 00:16:30,955
Now the secret, as we see, is the secret
key that is used for signing the cookie,

223
00:16:30,955 --> 00:16:36,310
and the store itself specifies
the session store instance that is used.

224
00:16:36,310 --> 00:16:39,810
The default is to use the in memory store.

225
00:16:39,810 --> 00:16:42,950
You can specify the file store or
Mongo store for

226
00:16:42,950 --> 00:16:46,000
storing that session information,
and so on.

227
00:16:46,000 --> 00:16:51,590
So once you specify this information for
your express session middleware then

228
00:16:51,590 --> 00:16:57,350
the session will be appropriately set up
and so will be tracked on the server side.

229
00:16:57,350 --> 00:17:02,430
Each client request will then be
mapped to the session information on

230
00:17:02,430 --> 00:17:08,260
the server side when the client request is
parsed by the express session middleware.

231
00:17:08,260 --> 00:17:12,960
And the req.session will be
added into the request object.

232
00:17:14,150 --> 00:17:19,010
With this understanding of cookies and
express sessions, let's move

233
00:17:19,010 --> 00:17:24,050
on to the exercise where will look at
how we will make use of cookies first.

234
00:17:24,050 --> 00:17:29,360
And then we'll look at how we will
make use of express Express sessions

235
00:17:29,360 --> 00:17:35,121
within our Express REST API application
that we have been working on so far.

236
00:17:35,121 --> 00:17:40,109
[MUSIC]