1
00:00:02,350 --> 00:00:04,400
So we had a closer look at cookies.

2
00:00:04,400 --> 00:00:07,260
Now I want to have a closer look at sessions

3
00:00:07,260 --> 00:00:10,780
and really show you that we can use sessions

4
00:00:10,780 --> 00:00:13,630
for other things than authentication as well.

5
00:00:13,630 --> 00:00:17,040
And for this I got a good example here on this page.

6
00:00:17,040 --> 00:00:19,550
Here we got this signup page.

7
00:00:19,550 --> 00:00:22,300
Now let's say we have an error here.

8
00:00:22,300 --> 00:00:24,150
When signing up here,

9
00:00:24,150 --> 00:00:27,233
I do enter two different email addresses here.

10
00:00:28,260 --> 00:00:30,983
Or I enter a password that's too short.

11
00:00:32,130 --> 00:00:35,630
This will then prevent the signup from succeeding

12
00:00:35,630 --> 00:00:38,020
because in our server-side code,

13
00:00:38,020 --> 00:00:39,750
in the signup route,

14
00:00:39,750 --> 00:00:42,530
we do have some validation here.

15
00:00:42,530 --> 00:00:45,520
And if the password is too short

16
00:00:45,520 --> 00:00:49,030
or if our two email addresses do not match,

17
00:00:49,030 --> 00:00:52,580
then we will be redirected back to the signup page

18
00:00:52,580 --> 00:00:55,320
and the signup process will fail.

19
00:00:55,320 --> 00:00:58,730
Therefore, for example here, if I try to create a user,

20
00:00:58,730 --> 00:01:01,300
I end up back on this signup page

21
00:01:01,300 --> 00:01:03,563
and this user was not created.

22
00:01:04,519 --> 00:01:06,730
As you can check by quickly having a look

23
00:01:06,730 --> 00:01:08,180
at all your users,

24
00:01:08,180 --> 00:01:09,973
we still only have one there.

25
00:01:11,010 --> 00:01:11,843
So that's good.

26
00:01:11,843 --> 00:01:14,322
We have this extra validation step,

27
00:01:14,322 --> 00:01:17,020
but the disadvantage of the current approach

28
00:01:17,020 --> 00:01:21,260
is that we're not providing a good user experience.

29
00:01:21,260 --> 00:01:23,470
We all know those websites

30
00:01:23,470 --> 00:01:25,650
where you enter your credentials

31
00:01:25,650 --> 00:01:27,740
and you make one tiny error,

32
00:01:27,740 --> 00:01:29,270
and you are redirected back,

33
00:01:29,270 --> 00:01:32,070
and all your input is cleared.

34
00:01:32,070 --> 00:01:34,380
You have to re-enter everything.

35
00:01:34,380 --> 00:01:35,330
I don't know about you

36
00:01:35,330 --> 00:01:37,750
but I'm not too happy when that happens.

37
00:01:37,750 --> 00:01:41,030
And it's happening here on this demo website.

38
00:01:41,030 --> 00:01:42,920
Of course it's just a demo website

39
00:01:42,920 --> 00:01:45,620
but we can still learn how to do it better.

40
00:01:45,620 --> 00:01:48,470
And here we can use sessions.

41
00:01:48,470 --> 00:01:51,530
Because of what do we want to achieve here?

42
00:01:51,530 --> 00:01:54,870
Well, we want to show this signup page again,

43
00:01:54,870 --> 00:01:58,170
but we want to keep all the values the user entered

44
00:01:58,170 --> 00:02:01,400
so that he or she can simply fix those values

45
00:02:01,400 --> 00:02:03,673
instead of having to retype everything.

46
00:02:05,010 --> 00:02:06,860
The problem we face here though

47
00:02:06,860 --> 00:02:08,919
is that we're redirecting.

48
00:02:08,919 --> 00:02:11,760
I am not returning

49
00:02:11,760 --> 00:02:16,000
a rendered template like this.

50
00:02:16,000 --> 00:02:18,940
I'm not doing this, instead I'm redirecting.

51
00:02:18,940 --> 00:02:21,110
And I am not doing this

52
00:02:21,110 --> 00:02:23,000
because if I would do that,

53
00:02:23,000 --> 00:02:25,560
if I would render a new template

54
00:02:25,560 --> 00:02:28,430
as a response instead of redirecting,

55
00:02:28,430 --> 00:02:31,160
what would happen is that now,

56
00:02:31,160 --> 00:02:33,070
if I reload here,

57
00:02:33,070 --> 00:02:36,053
and I again mess this up real quick here,

58
00:02:39,920 --> 00:02:42,130
then we still end up on this page.

59
00:02:42,130 --> 00:02:44,570
But if I now ever try to reload this page,

60
00:02:44,570 --> 00:02:46,417
I get this, "Do you want to send

61
00:02:46,417 --> 00:02:49,140
"the post request warning again?"

62
00:02:49,140 --> 00:02:51,130
Because this page here

63
00:02:51,130 --> 00:02:53,580
after messing up the data

64
00:02:53,580 --> 00:02:57,570
actually was rendered upon a post request.

65
00:02:57,570 --> 00:03:00,450
And we typically want to avoid sending back

66
00:03:00,450 --> 00:03:04,540
HTML content as a response for post requests

67
00:03:04,540 --> 00:03:07,160
because if a user then ever reloads the page,

68
00:03:07,160 --> 00:03:10,340
he or she gets this ugly warning.

69
00:03:10,340 --> 00:03:12,400
So that's why we want to prevent this.

70
00:03:12,400 --> 00:03:15,010
There also are some other reasons for doing it,

71
00:03:15,010 --> 00:03:16,640
but that's a big one.

72
00:03:16,640 --> 00:03:19,640
Therefore, way early in the course already,

73
00:03:19,640 --> 00:03:23,130
I explained to you that for post requests,

74
00:03:23,130 --> 00:03:25,580
you typically don't want to render

75
00:03:25,580 --> 00:03:27,370
a template as a response,

76
00:03:27,370 --> 00:03:31,020
instead you want to redirect to a get route instead.

77
00:03:31,020 --> 00:03:34,040
And redirect by default will send a get request

78
00:03:34,040 --> 00:03:35,640
to this path.

79
00:03:35,640 --> 00:03:38,370
And then we also load that same page again,

80
00:03:38,370 --> 00:03:40,160
but now through a get request

81
00:03:40,160 --> 00:03:42,380
and therefore, if the user ever reloads it

82
00:03:42,380 --> 00:03:43,460
or anything like that,

83
00:03:43,460 --> 00:03:47,120
he or she won't see this alert prompt.

84
00:03:47,120 --> 00:03:50,123
And therefore that's my preferred approach here.

85
00:03:51,350 --> 00:03:54,715
The disadvantage with redirecting here, though,

86
00:03:54,715 --> 00:03:59,715
is that if we do end up in this situation here,

87
00:04:00,118 --> 00:04:03,010
if I open my developer tools

88
00:04:03,010 --> 00:04:05,090
and go to the network tab,

89
00:04:05,090 --> 00:04:06,550
if I create user,

90
00:04:06,550 --> 00:04:09,520
we actually have two HTTP requests

91
00:04:09,520 --> 00:04:12,460
that are involved in loading this page.

92
00:04:12,460 --> 00:04:15,010
The first one is a redirect request,

93
00:04:15,010 --> 00:04:17,640
which has a 302 status code,

94
00:04:17,640 --> 00:04:19,836
which is the standard status code

95
00:04:19,836 --> 00:04:22,530
used for redirecting.

96
00:04:22,530 --> 00:04:26,630
And with this response, this 302 response,

97
00:04:26,630 --> 00:04:29,520
the final page, to which we want to redirect,

98
00:04:29,520 --> 00:04:31,240
isn't really loaded yet.

99
00:04:31,240 --> 00:04:33,800
Instead this just tells the browser,

100
00:04:33,800 --> 00:04:36,290
hey, please go to this page

101
00:04:36,290 --> 00:04:38,810
with a get request, in this case.

102
00:04:38,810 --> 00:04:41,270
Therefore the browser sends another request,

103
00:04:41,270 --> 00:04:42,860
the get request to this page,

104
00:04:42,860 --> 00:04:45,070
and this request actually leads

105
00:04:45,070 --> 00:04:46,633
to this page showing up.

106
00:04:47,680 --> 00:04:49,670
So we get two requests involved

107
00:04:49,670 --> 00:04:50,830
when we redirect.

108
00:04:50,830 --> 00:04:52,640
The first request and response

109
00:04:52,640 --> 00:04:55,630
that tells the browser that the browser should redirect.

110
00:04:55,630 --> 00:04:58,030
And then the real request and response

111
00:04:58,030 --> 00:05:00,993
that gives us the redirected-to page.

112
00:05:02,330 --> 00:05:04,800
Now, because all of that is the case,

113
00:05:04,800 --> 00:05:08,640
we can't use the data the user entered to us

114
00:05:08,640 --> 00:05:11,820
and just pass it along to the template.

115
00:05:11,820 --> 00:05:14,520
We could do that if we directly render the template,

116
00:05:14,520 --> 00:05:16,330
but we don't want to do that.

117
00:05:16,330 --> 00:05:18,470
And redirect doesn't allow us

118
00:05:18,470 --> 00:05:21,770
to send any data along to the page

119
00:05:21,770 --> 00:05:25,360
or to the route that will eventually be reached.

120
00:05:25,360 --> 00:05:27,520
So therefore here, we need a way

121
00:05:27,520 --> 00:05:31,830
of storing the input provided by the user

122
00:05:31,830 --> 00:05:35,350
somewhere on the server temporarily

123
00:05:35,350 --> 00:05:38,510
until that redirection flow finished,

124
00:05:38,510 --> 00:05:42,393
so until we are on that final signup page.

125
00:05:43,820 --> 00:05:47,030
And if we need to store data on the server

126
00:05:47,030 --> 00:05:50,350
temporarily, sessions are your friend.

127
00:05:50,350 --> 00:05:52,630
We don't just use them for authentication.

128
00:05:52,630 --> 00:05:54,640
Instead this use case here

129
00:05:54,640 --> 00:05:57,130
that you want to store some input data

130
00:05:57,130 --> 00:05:59,980
until the input page is presented again

131
00:05:59,980 --> 00:06:03,163
is a classic example for sessions as well.

132
00:06:04,770 --> 00:06:06,050
So here what we want to do,

133
00:06:06,050 --> 00:06:07,590
before we redirect,

134
00:06:07,590 --> 00:06:12,590
is we want to store that data in our session.

135
00:06:12,900 --> 00:06:15,600
So we can reach out to our session here,

136
00:06:15,600 --> 00:06:20,600
and add a inputData field to it, for example.

137
00:06:21,200 --> 00:06:22,480
The field name is up to you

138
00:06:22,480 --> 00:06:23,870
because you can add any data

139
00:06:23,870 --> 00:06:25,860
you want to your session.

140
00:06:25,860 --> 00:06:28,810
And then here, I will, for example,

141
00:06:28,810 --> 00:06:32,110
add a hasError flag and set this to true

142
00:06:32,110 --> 00:06:34,470
because the input data had an error.

143
00:06:34,470 --> 00:06:36,423
That's why we're redirecting here.

144
00:06:37,460 --> 00:06:40,160
We can add a message if we want to,

145
00:06:40,160 --> 00:06:43,727
where we, for example, say "Invalid input.

146
00:06:43,727 --> 00:06:46,087
"Please check your data."

147
00:06:47,050 --> 00:06:50,750
And we could use this message for showing it to the user.

148
00:06:50,750 --> 00:06:54,230
I'll show you how to do that in a couple of seconds.

149
00:06:54,230 --> 00:06:56,120
And then most importantly,

150
00:06:56,120 --> 00:06:59,830
I'll store the enteredEmail in an email field.

151
00:06:59,830 --> 00:07:02,210
I'll store the confirm email,

152
00:07:02,210 --> 00:07:06,160
the enteredConfirmEmail in a confirmEmail field.

153
00:07:06,160 --> 00:07:08,880
And I'll store the enteredPassword

154
00:07:08,880 --> 00:07:10,373
in a password field.

155
00:07:12,320 --> 00:07:15,670
And now we still redirect without anything else,

156
00:07:15,670 --> 00:07:19,563
but we stored this data here in our session.

157
00:07:21,020 --> 00:07:23,250
Please note that this session data

158
00:07:23,250 --> 00:07:26,430
has nothing to do with authentication.

159
00:07:26,430 --> 00:07:28,330
So setting this session data

160
00:07:28,330 --> 00:07:31,740
will not grant access to the admin page

161
00:07:31,740 --> 00:07:33,090
because there we're looking

162
00:07:33,090 --> 00:07:36,030
for a totally different piece of data in the session.

163
00:07:36,030 --> 00:07:38,860
And that's exactly what I'm trying to convey here.

164
00:07:38,860 --> 00:07:41,610
Sessions can be used for all kinds of data,

165
00:07:41,610 --> 00:07:44,003
not just for authentication purposes.

166
00:07:45,320 --> 00:07:48,320
Now, just as before, I am then redirecting

167
00:07:48,320 --> 00:07:51,250
to a page that will rely on this data

168
00:07:51,250 --> 00:07:52,720
because I'm saving that data

169
00:07:52,720 --> 00:07:55,170
to show it on the redirected page.

170
00:07:55,170 --> 00:07:57,760
And therefore here I will actually, again,

171
00:07:57,760 --> 00:08:00,270
call save manually

172
00:08:00,270 --> 00:08:02,250
so that we can provide a function

173
00:08:02,250 --> 00:08:03,480
that will be executed

174
00:08:03,480 --> 00:08:06,230
once saving to the database finished.

175
00:08:06,230 --> 00:08:08,100
And I only want to redirect

176
00:08:08,100 --> 00:08:11,120
after that session was saved

177
00:08:11,120 --> 00:08:12,420
so that we can be sure

178
00:08:12,420 --> 00:08:14,230
that only redirected page

179
00:08:14,230 --> 00:08:16,613
will have access to that session data.

180
00:08:17,920 --> 00:08:21,270
Because that is now the second step.

181
00:08:21,270 --> 00:08:24,370
We're storing that data in the session.

182
00:08:24,370 --> 00:08:27,970
Now on the get route here for signup,

183
00:08:27,970 --> 00:08:31,840
I want to check if I do have such stored data.

184
00:08:31,840 --> 00:08:34,990
Of course, we'll not always have stored data.

185
00:08:34,990 --> 00:08:37,919
If we visit the signup page for the first time,

186
00:08:37,919 --> 00:08:41,049
for example, we didn't try to submit it yet,

187
00:08:41,049 --> 00:08:43,870
and therefore we won't have the inputData field

188
00:08:43,870 --> 00:08:45,050
in the session.

189
00:08:45,050 --> 00:08:46,900
But if we messed up the signup,

190
00:08:46,900 --> 00:08:47,973
we will have it.

191
00:08:49,610 --> 00:08:50,950
So here we can add a variable

192
00:08:50,950 --> 00:08:53,740
with my session input data,

193
00:08:53,740 --> 00:08:55,490
or however you want to name it,

194
00:08:55,490 --> 00:08:59,027
where I access request.session.inputData.

195
00:09:02,293 --> 00:09:05,210
And of course, that here should be the same key

196
00:09:05,210 --> 00:09:08,683
as was chosen down there for storing the data.

197
00:09:11,840 --> 00:09:15,120
Now this might be null or undefined

198
00:09:15,120 --> 00:09:18,480
if no data was stored in the session before,

199
00:09:18,480 --> 00:09:20,120
and therefore I want to check

200
00:09:20,120 --> 00:09:25,120
if I maybe don't have session input data,

201
00:09:25,130 --> 00:09:27,010
if this is null or undefined

202
00:09:27,010 --> 00:09:29,940
or false in any other way.

203
00:09:29,940 --> 00:09:33,810
In that case, I want to set it to a default value,

204
00:09:33,810 --> 00:09:36,840
which actually will be,

205
00:09:36,840 --> 00:09:39,380
which actually will be an object

206
00:09:40,810 --> 00:09:44,450
where I set hasError to false

207
00:09:44,450 --> 00:09:46,740
because we haven't stored any input data,

208
00:09:46,740 --> 00:09:49,470
so we clearly didn't have an error.

209
00:09:49,470 --> 00:09:52,350
And where I set email to an empty string,

210
00:09:52,350 --> 00:09:55,730
confirmEmail to an empty string,

211
00:09:55,730 --> 00:09:58,160
and password to an empty string

212
00:09:58,160 --> 00:10:01,270
because we don't have any data stored in a session yet,

213
00:10:01,270 --> 00:10:03,380
so we clearly are visiting this page

214
00:10:03,380 --> 00:10:04,870
for the first time.

215
00:10:04,870 --> 00:10:06,900
We didn't submit it before.

216
00:10:06,900 --> 00:10:08,690
So I will set all these values

217
00:10:08,690 --> 00:10:10,513
to empty initial states.

218
00:10:11,710 --> 00:10:14,420
And I'm doing this so that now either way,

219
00:10:14,420 --> 00:10:16,630
if we got it in the session or not,

220
00:10:16,630 --> 00:10:19,440
I can send this session input data

221
00:10:19,440 --> 00:10:21,240
into my template.

222
00:10:21,240 --> 00:10:23,780
Here I'll add our inputData key

223
00:10:23,780 --> 00:10:27,140
and set this equal to a sessionInputData,

224
00:10:27,140 --> 00:10:29,420
which is now either that default object

225
00:10:29,420 --> 00:10:32,100
or the real object with all the data

226
00:10:32,100 --> 00:10:33,913
that was stored in the session.

227
00:10:35,670 --> 00:10:37,000
Now with that,

228
00:10:37,000 --> 00:10:38,510
we can go to the template

229
00:10:38,510 --> 00:10:41,820
and utilize this inputData field.

230
00:10:41,820 --> 00:10:44,060
So we can go to the signup template

231
00:10:44,060 --> 00:10:46,623
and use this data there.

232
00:10:48,260 --> 00:10:50,470
Here, for example, we can first of all

233
00:10:50,470 --> 00:10:53,310
show the error message if we have an error,

234
00:10:53,310 --> 00:10:56,020
maybe below the h1 tag.

235
00:10:56,020 --> 00:10:57,830
We can use EJS to check

236
00:10:57,830 --> 00:11:01,653
if inputData.hasError is true,

237
00:11:02,650 --> 00:11:05,560
which it only is if we're having an error.

238
00:11:05,560 --> 00:11:07,940
Otherwise it will have this false value,

239
00:11:07,940 --> 00:11:09,913
which we set a couple of seconds ago.

240
00:11:11,900 --> 00:11:13,410
If we do have an error, though,

241
00:11:13,410 --> 00:11:15,880
we can show a paragraph here

242
00:11:15,880 --> 00:11:17,830
with an ID of input error

243
00:11:17,830 --> 00:11:20,700
for which I provided some styling.

244
00:11:20,700 --> 00:11:25,700
And in there we can then output inputData.message.

245
00:11:26,080 --> 00:11:28,340
So that's this message key,

246
00:11:28,340 --> 00:11:29,960
which I'm also sending

247
00:11:29,960 --> 00:11:31,453
if we do have an error.

248
00:11:32,420 --> 00:11:34,563
This message here if we have an error.

249
00:11:35,600 --> 00:11:37,080
So that's what I output here,

250
00:11:37,080 --> 00:11:39,590
the message if we have an error,

251
00:11:39,590 --> 00:11:43,130
and then I also want to pre-populate all these inputs

252
00:11:43,130 --> 00:11:46,130
with the default values

253
00:11:46,130 --> 00:11:49,410
that are set if we didn't have

254
00:11:49,410 --> 00:11:51,790
any input data in the session.

255
00:11:51,790 --> 00:11:54,240
So this default data here.

256
00:11:54,240 --> 00:11:57,900
Or with the actual user data that was entered before,

257
00:11:57,900 --> 00:11:59,900
which I did store in the session

258
00:11:59,900 --> 00:12:01,893
in case of an invalid input.

259
00:12:02,890 --> 00:12:06,370
So I want to pre-populate those inputs with those values,

260
00:12:06,370 --> 00:12:10,000
and we can do that with the value attributes.

261
00:12:10,000 --> 00:12:13,560
Here we can use EJS to set a default value,

262
00:12:13,560 --> 00:12:15,610
and that's inputData.email for the email,

263
00:12:16,908 --> 00:12:18,480
and so on.

264
00:12:18,480 --> 00:12:21,730
So down here, it's inputData.confirm,

265
00:12:21,730 --> 00:12:22,563
whoops,

266
00:12:24,221 --> 00:12:25,304
confirmEmail.

267
00:12:27,870 --> 00:12:30,530
And here for the password,

268
00:12:30,530 --> 00:12:33,663
it's inputData.password.

269
00:12:35,660 --> 00:12:36,493
Like that.

270
00:12:37,910 --> 00:12:40,430
Now with that, if we visit

271
00:12:40,430 --> 00:12:42,840
the singup page for the first time,

272
00:12:42,840 --> 00:12:44,988
if I go to a different page and come back,

273
00:12:44,988 --> 00:12:47,700
it's empty because now we have

274
00:12:47,700 --> 00:12:49,490
no input data in the session,

275
00:12:49,490 --> 00:12:51,230
and hence the default values,

276
00:12:51,230 --> 00:12:54,040
which are those empty strings, are set here.

277
00:12:54,040 --> 00:12:56,283
We also don't see any error message.

278
00:12:57,420 --> 00:12:59,920
But if I do now create a new user

279
00:12:59,920 --> 00:13:03,970
and I do enter some invalid credentials here.

280
00:13:03,970 --> 00:13:06,310
If I click Create user,

281
00:13:06,310 --> 00:13:07,820
now we are redirected,

282
00:13:07,820 --> 00:13:10,970
but now our entered data is preserved

283
00:13:10,970 --> 00:13:12,833
and we see this error message.

284
00:13:14,120 --> 00:13:16,240
Though, you will notice that if you now try

285
00:13:16,240 --> 00:13:18,260
to visit any other page,

286
00:13:18,260 --> 00:13:19,550
this will fail

287
00:13:19,550 --> 00:13:22,350
because our server actually crashed.

288
00:13:22,350 --> 00:13:24,110
We'll fix this in a second.

289
00:13:24,110 --> 00:13:25,590
But before we fix this,

290
00:13:25,590 --> 00:13:27,500
it is worth noting that we were able

291
00:13:27,500 --> 00:13:29,500
to preserve the entered data

292
00:13:29,500 --> 00:13:31,483
and show this error message.

293
00:13:32,780 --> 00:13:36,200
But now why does our server crash here?

294
00:13:36,200 --> 00:13:39,820
The reason for that can be found in the post signup page.

295
00:13:39,820 --> 00:13:44,043
Here, I am redirecting after I saved my session.

296
00:13:44,910 --> 00:13:47,750
The problem is that if I return here,

297
00:13:47,750 --> 00:13:51,210
then I'm returning in this anonymous function.

298
00:13:51,210 --> 00:13:53,860
So returning in here will not prevent

299
00:13:53,860 --> 00:13:56,310
the other code from executing here.

300
00:13:56,310 --> 00:13:59,550
Instead, it only prevents other code

301
00:13:59,550 --> 00:14:02,570
inside of this anonymous function from executing.

302
00:14:02,570 --> 00:14:05,100
And there is no other code here.

303
00:14:05,100 --> 00:14:07,920
Therefore actually, I did redirect,

304
00:14:07,920 --> 00:14:10,920
but then all that code here still executed,

305
00:14:10,920 --> 00:14:13,740
and therefore actually, I did even create

306
00:14:13,740 --> 00:14:15,860
this user in the database.

307
00:14:15,860 --> 00:14:18,690
And then I redirected again.

308
00:14:18,690 --> 00:14:20,770
I sent back two responses

309
00:14:20,770 --> 00:14:24,450
and that's not something Node Express likes.

310
00:14:24,450 --> 00:14:27,737
That's why you get an error like "Cannot set headers

311
00:14:27,737 --> 00:14:28,880
"after they are sent,"

312
00:14:28,880 --> 00:14:31,400
because we tried to send another response

313
00:14:31,400 --> 00:14:34,010
and therefore sent new response headers

314
00:14:34,010 --> 00:14:36,520
after already sending one.

315
00:14:36,520 --> 00:14:38,140
The fix is easy.

316
00:14:38,140 --> 00:14:41,470
We just also have to return

317
00:14:42,370 --> 00:14:44,900
after saving our session

318
00:14:44,900 --> 00:14:46,440
so that we still ensure

319
00:14:46,440 --> 00:14:48,170
that in this main function here,

320
00:14:48,170 --> 00:14:50,343
this code down there doesn't execute.

321
00:14:51,680 --> 00:14:53,690
On the other hand, we don't need to return

322
00:14:53,690 --> 00:14:55,160
in this anonymous function

323
00:14:55,160 --> 00:14:57,300
because there is no code in there,

324
00:14:57,300 --> 00:15:00,670
which we would want to prevent from executing.

325
00:15:00,670 --> 00:15:03,060
So we should return after saving the session.

326
00:15:03,060 --> 00:15:04,483
That's important here.

327
00:15:05,690 --> 00:15:07,710
And now, of course, I also briefly want

328
00:15:07,710 --> 00:15:10,966
to have a look at my users and delete that user,

329
00:15:10,966 --> 00:15:13,660
which I accidentally created,

330
00:15:13,660 --> 00:15:18,406
simply by running db users deleteOne,

331
00:15:18,406 --> 00:15:20,753
and then using the email for that user

332
00:15:20,753 --> 00:15:22,223
that I used before.

333
00:15:23,520 --> 00:15:26,023
So that I clear this erroneous user.

334
00:15:27,240 --> 00:15:30,230
With all of that, if you now stop that server

335
00:15:30,230 --> 00:15:32,080
and restart it,

336
00:15:32,080 --> 00:15:34,930
you should be able to visit the pages again.

337
00:15:34,930 --> 00:15:38,293
And now if you submit this invalid data again,

338
00:15:39,170 --> 00:15:40,773
the server didn't crash,

339
00:15:41,690 --> 00:15:45,770
and now this user also wasn't created here.

340
00:15:45,770 --> 00:15:47,730
So now that's this bug fixed.

341
00:15:47,730 --> 00:15:49,890
And now we preserve that data

342
00:15:49,890 --> 00:15:52,220
so that the user is now able to correct it

343
00:15:52,220 --> 00:15:54,313
and then submit valid data.

344
00:15:56,110 --> 00:15:58,000
However, you'll notice a problem.

345
00:15:58,000 --> 00:16:00,150
I do now do that and this worked

346
00:16:00,150 --> 00:16:02,110
because I entered valid data,

347
00:16:02,110 --> 00:16:03,750
and hence I could now log in

348
00:16:03,750 --> 00:16:05,670
with that newly created user.

349
00:16:05,670 --> 00:16:07,570
But if I visit the signup page,

350
00:16:07,570 --> 00:16:09,660
the data is still there.

351
00:16:09,660 --> 00:16:12,880
It's there even after I reload and so on.

352
00:16:12,880 --> 00:16:16,240
And it's still there because it's stored in the session.

353
00:16:16,240 --> 00:16:19,440
And thankfully, data doesn't randomly disappear

354
00:16:19,440 --> 00:16:20,730
in the session.

355
00:16:20,730 --> 00:16:24,580
That would be pretty bad for our authentication use case.

356
00:16:24,580 --> 00:16:27,120
Instead, data exists in a session

357
00:16:27,120 --> 00:16:28,940
until the session expires

358
00:16:28,940 --> 00:16:31,860
or you manually delete it.

359
00:16:31,860 --> 00:16:34,050
Like we're doing it in the log out route.

360
00:16:34,050 --> 00:16:36,750
There we are deleting the authentication data

361
00:16:36,750 --> 00:16:39,323
from the session when the user logs out.

362
00:16:40,520 --> 00:16:43,210
Now for this validation use case here,

363
00:16:43,210 --> 00:16:45,820
where I'm storing this entered data

364
00:16:45,820 --> 00:16:48,630
to provide a better user experience,

365
00:16:48,630 --> 00:16:50,650
I actually want to clear the data

366
00:16:50,650 --> 00:16:51,820
from the session

367
00:16:51,820 --> 00:16:54,600
right after presenting that data

368
00:16:54,600 --> 00:16:57,403
to the user on the signup page again.

369
00:16:58,320 --> 00:17:01,190
So here, in this get signup route,

370
00:17:01,190 --> 00:17:03,640
right after extracting the data

371
00:17:03,640 --> 00:17:05,530
from the session and using it,

372
00:17:05,530 --> 00:17:06,963
I want to delete it.

373
00:17:07,940 --> 00:17:10,780
So here, before I even rendered a template,

374
00:17:10,780 --> 00:17:12,819
I'll go to request session

375
00:17:12,819 --> 00:17:15,550
and set the inputData for that user

376
00:17:15,550 --> 00:17:17,990
to null again,

377
00:17:17,990 --> 00:17:19,623
to effectively clear it.

378
00:17:20,619 --> 00:17:22,230
We extracted it before,

379
00:17:22,230 --> 00:17:24,770
so it's still stored in this variable,

380
00:17:24,770 --> 00:17:27,200
and we can still send it to the template.

381
00:17:27,200 --> 00:17:28,670
That will still work.

382
00:17:28,670 --> 00:17:31,870
But we also clear it from the session thereafter.

383
00:17:31,870 --> 00:17:32,757
And as mentioned before,

384
00:17:32,757 --> 00:17:34,290
the session will be saved

385
00:17:34,290 --> 00:17:35,970
to the database automatically.

386
00:17:35,970 --> 00:17:38,000
And here we don't need to ensure

387
00:17:38,000 --> 00:17:41,367
that saving was done because for this page,

388
00:17:41,367 --> 00:17:43,090
for this template, which we render,

389
00:17:43,090 --> 00:17:46,253
we now don't directly rely on the session anymore.

390
00:17:47,570 --> 00:17:48,990
But by resetting it here,

391
00:17:48,990 --> 00:17:51,650
we ensure that the data is only kept around

392
00:17:51,650 --> 00:17:53,950
temporarily in the session

393
00:17:53,950 --> 00:17:56,070
until the redirect finished

394
00:17:56,070 --> 00:17:58,230
and until we extracted the data

395
00:17:58,230 --> 00:18:00,580
from the session once.

396
00:18:00,580 --> 00:18:02,450
And that's absolutely something

397
00:18:02,450 --> 00:18:05,003
we should do here for this use case.

398
00:18:06,110 --> 00:18:08,860
So you can use sessions for different use cases,

399
00:18:08,860 --> 00:18:11,040
and it depends on the use case

400
00:18:11,040 --> 00:18:13,410
how long you want to store your data.

401
00:18:13,410 --> 00:18:17,610
Here, I only want to store it for one request.

402
00:18:17,610 --> 00:18:20,840
This technique is also called flashing,

403
00:18:20,840 --> 00:18:23,850
where flashing a value onto the session

404
00:18:23,850 --> 00:18:26,083
just to have it for the next request

405
00:18:26,083 --> 00:18:27,380
after a redirect,

406
00:18:27,380 --> 00:18:29,453
and thereafter it's cleared again.

407
00:18:30,660 --> 00:18:34,580
With this now, if I reload this page again,

408
00:18:34,580 --> 00:18:35,670
and then again,

409
00:18:35,670 --> 00:18:37,810
now the data is gone.

410
00:18:37,810 --> 00:18:40,790
So now if I try to create a user here

411
00:18:40,790 --> 00:18:43,340
and I mess up the data,

412
00:18:43,340 --> 00:18:45,350
I still get this better user experience

413
00:18:45,350 --> 00:18:47,500
of showing the error and so on.

414
00:18:47,500 --> 00:18:50,310
But if I come back to the page in the future,

415
00:18:50,310 --> 00:18:52,460
it's not there anymore

416
00:18:52,460 --> 00:18:55,763
because we clear it after presenting the page once.

417
00:18:56,750 --> 00:18:59,690
And that's how we can also use sessions here

418
00:18:59,690 --> 00:19:01,883
for validation purposes.

