1
00:00:01,210 --> 00:00:04,650
‫Instrutor: E agora vamos finalmente criar a última parte

2
00:00:04,650 --> 00:00:07,010
‫da Funcionalidade de Redefinição de

3
00:00:07,010 --> 00:00:10,593
‫Senha, onde realmente definimos a nova senha para o usuário.

4
00:00:12,250 --> 00:00:15,900
‫E então, assim como antes, vamos começar definindo

5
00:00:15,900 --> 00:00:19,713
‫as etapas que iremos realizar para este fluxo de resetPassword.

6
00:00:21,240 --> 00:00:26,240
‫Portanto, primeiro, obtenha o usuário com base no token.

7
00:00:30,350 --> 00:00:35,350
‫Em seguida, como segunda etapa, definiremos a nova senha, mas

8
00:00:35,890 --> 00:00:40,153
‫apenas se o token não tiver expirado e

9
00:00:42,070 --> 00:00:44,040
‫houver um usuário.

10
00:00:44,040 --> 00:00:48,633
‫Nesse caso, defina a nova senha.

11
00:00:51,580 --> 00:00:55,250
‫Depois disso, precisamos atualizar a propriedade changedPasswordAt

12
00:00:57,210 --> 00:01:01,000
‫para o usuário atual e, finalmente, como

13
00:01:04,080 --> 00:01:05,403
‫é normal nesta

14
00:01:07,320 --> 00:01:10,533
‫funcionalidade, é fazer o login do

15
00:01:11,680 --> 00:01:12,853
‫usuário.

16
00:01:14,010 --> 00:01:18,840
‫Basicamente, envie o JSON Web Token ao cliente.

17
00:01:18,840 --> 00:01:22,733
‫Ok, muito trabalho a fazer, então vamos começar.

18
00:01:23,950 --> 00:01:27,493
‫E então, lembre-se do último vídeo, que o token

19
00:01:27,493 --> 00:01:30,450
‫de redefinição que é realmente enviado na URL

20
00:01:30,450 --> 00:01:33,110
‫é esse token não criptografado aqui.

21
00:01:33,110 --> 00:01:34,723
‫Então, na verdade este.

22
00:01:35,570 --> 00:01:37,810
‫Mas o que temos no banco

23
00:01:37,810 --> 00:01:39,680
‫de dados é o criptografado.

24
00:01:39,680 --> 00:01:42,580
‫Falamos sobre isso antes e, portanto, o que agora

25
00:01:42,580 --> 00:01:44,910
‫precisamos fazer é basicamente criptografar o token

26
00:01:44,910 --> 00:01:46,630
‫original novamente, para que

27
00:01:46,630 --> 00:01:49,240
‫possamos compará-lo com aquele que está armazenado, ou

28
00:01:49,240 --> 00:01:51,433
‫seja, o criptografado no banco de dados.

29
00:01:52,870 --> 00:01:55,110
‫Então, nós realmente fizemos algo semelhante

30
00:01:55,110 --> 00:01:57,890
‫antes com a senha, mas com a

31
00:01:57,890 --> 00:02:01,010
‫senha, não poderíamos compará-la tão facilmente quanto podemos com

32
00:02:01,010 --> 00:02:02,650
‫esta, novamente porque

33
00:02:02,650 --> 00:02:05,770
‫para a senha usamos o algoritmo bcrypt bastante complexo,

34
00:02:05,770 --> 00:02:07,490
‫que neste caso, nós não.

35
00:02:07,490 --> 00:02:09,750
‫Portanto, aqui é muito simples.

36
00:02:09,750 --> 00:02:13,040
‫Tudo o que precisamos fazer novamente é criptografar

37
00:02:13,040 --> 00:02:17,390
‫o token e compará-lo com o criptografado no banco de dados.

38
00:02:17,390 --> 00:02:22,390
‫Então, digamos hashedToken, e agora vamos precisar do

39
00:02:23,670 --> 00:02:26,813
‫pacote crypto aqui também.

40
00:02:31,730 --> 00:02:36,167
‫Const crypto e depois require ('crypto').

41
00:02:41,280 --> 00:02:42,123
‫Agora está certo.

42
00:02:43,780 --> 00:02:47,593
‫Então vamos voltar, e então, usamos

43
00:02:48,750 --> 00:02:51,610
‫criptografia. createHash.

44
00:02:53,070 --> 00:02:57,973
‫Lembre-se, então, do nome do algoritmo

45
00:02:58,910 --> 00:03:03,910
‫novamente, sha256, então. atualizar, basicamente para o local, para a

46
00:03:04,140 --> 00:03:06,040
‫string que queremos hash.

47
00:03:06,040 --> 00:03:10,110
‫E assim, esse é, lembre-se no req. params.

48
00:03:10,110 --> 00:03:14,083
‫Então, usamos este por um longo tempo. símbolo.

49
00:03:15,060 --> 00:03:17,950
‫E então, novamente, é um

50
00:03:17,950 --> 00:03:22,233
‫parâmetro, porque especificamos isso aqui na URL, assim.

51
00:03:23,250 --> 00:03:26,470
‫Então, agora é um parâmetro chamado token.

52
00:03:26,470 --> 00:03:31,470
‫E então, é claro, aqui está o req. params. símbolo.

53
00:03:31,804 --> 00:03:34,790
‫E então, finalmente, também precisamos dizer digerir

54
00:03:36,840 --> 00:03:38,633
‫e convertê-lo em hexadecimal.

55
00:03:40,380 --> 00:03:42,760
‫Agora, isso é basicamente o mesmo

56
00:03:42,760 --> 00:03:46,180
‫que tínhamos antes, onde criptografamos o original e,

57
00:03:46,180 --> 00:03:49,520
‫portanto, poderíamos refatorá-lo em sua própria função, mas

58
00:03:49,520 --> 00:03:51,693
‫vamos mantê-lo simples aqui.

59
00:03:54,240 --> 00:03:58,930
‫Portanto, agora vamos realmente obter o usuário com base neste token.

60
00:03:58,930 --> 00:04:01,060
‫Porque essa é, na verdade, a

61
00:04:01,060 --> 00:04:03,530
‫única coisa que sabemos sobre o usuário no momento.

62
00:04:03,530 --> 00:04:07,080
‫Não temos e-mail, não temos nada, então esse token é

63
00:04:07,080 --> 00:04:10,130
‫a única coisa que pode identificar o usuário.

64
00:04:10,130 --> 00:04:12,520
‫E agora podemos, basicamente, consultar o banco de

65
00:04:12,520 --> 00:04:14,170
‫dados para este token.

66
00:04:14,170 --> 00:04:17,303
‫Em seguida, ele encontrará o usuário que possui esse token.

67
00:04:19,230 --> 00:04:24,230
‫Então, aguarde, como já sabemos, e depois Usuário. findOne.

68
00:04:27,790 --> 00:04:31,213
‫Portanto, essa propriedade é chamada

69
00:04:32,090 --> 00:04:36,117
‫de passwordResetToken e estamos procurando o hashedToken.

70
00:04:37,940 --> 00:04:42,220
‫E agora, é claro, precisamos declará-lo como assíncrono e

71
00:04:43,150 --> 00:04:44,643
‫prepará-lo para catchAsync.

72
00:04:48,557 --> 00:04:51,810
‫Salve-o, isso deve corrigir o bug, e

73
00:04:51,810 --> 00:04:53,950
‫de fato corrige.

74
00:04:53,950 --> 00:04:56,950
‫Assim, ele encontrará o usuário que possui o

75
00:04:56,950 --> 00:04:59,100
‫token que enviará via URL.

76
00:04:59,100 --> 00:05:00,910
‫Mas, no momento, não estamos

77
00:05:00,910 --> 00:05:04,090
‫levando em consideração a data de expiração do token.

78
00:05:04,090 --> 00:05:06,000
‫E então, como poderíamos fazer isso?

79
00:05:06,000 --> 00:05:09,020
‫Bem, basicamente, o que queremos é verificar

80
00:05:09,020 --> 00:05:11,860
‫se a propriedade passwordResetExpires é maior

81
00:05:11,860 --> 00:05:13,723
‫do que agora.

82
00:05:14,890 --> 00:05:17,350
‫Porque se a data de validade for maior do

83
00:05:17,350 --> 00:05:20,420
‫que agora, significa que está no futuro, o que por sua

84
00:05:20,420 --> 00:05:22,313
‫vez significa que ainda não expirou.

85
00:05:23,180 --> 00:05:24,850
‫E essa é uma maneira

86
00:05:24,850 --> 00:05:28,343
‫muito fácil de fazermos isso da maneira certa com essa consulta.

87
00:05:30,619 --> 00:05:32,702
‫Então, passwordResetExpires, que é onde essa

88
00:05:35,170 --> 00:05:37,460
‫data é armazenada, e agora tudo o

89
00:05:37,460 --> 00:05:38,840
‫que precisamos verificar

90
00:05:38,840 --> 00:05:41,470
‫se ela é realmente maior do que agora.

91
00:05:41,470 --> 00:05:45,440
‫E então já sabemos como fazer isso com o MongoDB, certo?

92
00:05:45,440 --> 00:05:50,110
‫Então, novo objeto e então o maior operador e então o que queremos

93
00:05:50,110 --> 00:05:53,737
‫compará-lo é a data. agora, e este será realmente

94
00:05:56,310 --> 00:05:59,410
‫um registro de data e hora de agora,

95
00:05:59,410 --> 00:06:02,900
‫mas nos bastidores, o MongoDB converterá tudo para o

96
00:06:02,900 --> 00:06:05,170
‫mesmo e, portanto, será capaz de

97
00:06:05,170 --> 00:06:06,520
‫compará-los com precisão.

98
00:06:08,070 --> 00:06:10,440
‫E assim podemos, ao mesmo tempo,

99
00:06:10,440 --> 00:06:14,120
‫encontrar o usuário para o token e também verificar se

100
00:06:14,120 --> 00:06:16,370
‫o token ainda não expirou.

101
00:06:16,370 --> 00:06:18,190
‫Tão bom.

102
00:06:18,190 --> 00:06:21,190
‫Então, a seguir queremos, é claro, enviar um

103
00:06:21,190 --> 00:06:25,530
‫erro se não houver usuário, ou basicamente, se o token tiver expirado.

104
00:06:25,530 --> 00:06:27,230
‫Mas isso, neste caso,

105
00:06:27,230 --> 00:06:30,500
‫é o mesmo, porque se o token expirou, então

106
00:06:30,500 --> 00:06:32,513
‫ele simplesmente não retornará nenhum usuário.

107
00:06:33,956 --> 00:06:37,730
‫E então tudo o que precisamos fazer é dizer,

108
00:06:38,970 --> 00:06:43,970
‫se nenhum usuário, bem, então, como sempre, volte em seguida, isso não é mext.

109
00:06:47,920 --> 00:06:51,910
‫Portanto, novo AppError, e digamos

110
00:06:51,910 --> 00:06:56,793
‫que o Token é inválido ou expirou.

111
00:06:59,850 --> 00:07:02,853
‫E então 400, pedido tão ruim.

112
00:07:04,140 --> 00:07:07,050
‫E então, se não houver erro

113
00:07:07,050 --> 00:07:09,400
‫e se next não

114
00:07:09,400 --> 00:07:12,160
‫for chamado, vamos definir a senha.

115
00:07:12,160 --> 00:07:15,550
‫Então, já pegamos o usuário e agora é muito

116
00:07:15,550 --> 00:07:20,550
‫simples: usuário. a senha é igual a req. corpo. senha.

117
00:07:24,880 --> 00:07:28,140
‫E isso porque, é claro, enviaremos a

118
00:07:28,140 --> 00:07:31,713
‫senha e também a passwordConfirm por meio do corpo.

119
00:07:33,551 --> 00:07:34,701
‫Então, vamos

120
00:07:37,870 --> 00:07:39,553
‫duplicar isso e também passwordConfirm.

121
00:07:41,425 --> 00:07:44,630
‫E também, vamos basicamente excluir o token de redefinição

122
00:07:44,630 --> 00:07:45,733
‫e o expirado.

123
00:07:46,800 --> 00:07:51,800
‫Portanto, passwordResetToken, assim como fizemos antes, definimos como undefined,

124
00:07:52,040 --> 00:07:57,037
‫e agora user. a senha expira é igual

125
00:07:59,510 --> 00:08:01,160
‫a indefinida.

126
00:08:01,160 --> 00:08:02,220
‫Tudo bem.

127
00:08:02,220 --> 00:08:04,350
‫E de novo, é claro, agora precisamos

128
00:08:04,350 --> 00:08:07,000
‫salvá-lo, porque isso apenas modifica o documento, na verdade

129
00:08:07,000 --> 00:08:08,410
‫não é atualizado.

130
00:08:08,410 --> 00:08:09,973
‫Portanto, não o salva realmente.

131
00:08:11,200 --> 00:08:15,503
‫Portanto, aguarde o usuário. Salve .

132
00:08:17,500 --> 00:08:20,350
‫E, neste caso, não precisamos

133
00:08:20,350 --> 00:08:24,340
‫desligar os validadores, porque realmente queremos validar.

134
00:08:24,340 --> 00:08:27,620
‫Por exemplo, queremos que o validador

135
00:08:27,620 --> 00:08:31,440
‫confirme se a senha é igual a passwordConfirm.

136
00:08:31,440 --> 00:08:33,380
‫E então esse validador faz todo

137
00:08:33,380 --> 00:08:35,033
‫esse trabalho automaticamente para nós.

138
00:08:36,800 --> 00:08:39,390
‫Em seguida, a terceira etapa, o que realmente

139
00:08:39,390 --> 00:08:42,030
‫faremos no final, e o que faremos a seguir

140
00:08:42,030 --> 00:08:43,990
‫é basicamente bloquear o usuário.

141
00:08:43,990 --> 00:08:47,400
‫Em outras palavras, envie o JSON Web Token.

142
00:08:47,400 --> 00:08:51,930
‫E vamos pegar aquele código daqui, então este.

143
00:08:51,930 --> 00:08:53,770
‫E, novamente, já estamos fazendo

144
00:08:53,770 --> 00:08:55,700
‫isso aqui em três lugares diferentes.

145
00:08:55,700 --> 00:08:59,280
‫Então aqui no login, também no cadastro, e agora

146
00:08:59,280 --> 00:09:01,400
‫pela terceira vez, aqui embaixo.

147
00:09:01,400 --> 00:09:05,170
‫E então, em algum momento no futuro, iremos refatorar isso em

148
00:09:05,170 --> 00:09:06,383
‫sua própria função.

149
00:09:07,230 --> 00:09:09,673
‫Mas, por enquanto, estamos bem assim.

150
00:09:11,180 --> 00:09:14,743
‫E então, vamos realmente prosseguir e testar isso.

151
00:09:16,710 --> 00:09:19,020
‫Portanto, esse token de

152
00:09:19,020 --> 00:09:22,080
‫redefinição que tínhamos antes já expirou e,

153
00:09:22,080 --> 00:09:24,640
‫basicamente, precisamos pedir um novo.

154
00:09:24,640 --> 00:09:29,490
‫Então, vamos ao Postman e decidamos esquecer a senha.

155
00:09:29,490 --> 00:09:32,120
‫Vamos apenas reduzir a desordem aqui

156
00:09:32,120 --> 00:09:36,350
‫e nos livrar de todas essas guias abertas de que não

157
00:09:36,350 --> 00:09:37,500
‫precisamos mais.

158
00:09:38,910 --> 00:09:41,150
‫Na verdade, vamos precisar desse teste

159
00:09:43,480 --> 00:09:45,270
‫para redefinir a senha, porque

160
00:09:45,270 --> 00:09:48,210
‫lembre-se de que este realmente recebe um JSON

161
00:09:48,210 --> 00:09:51,540
‫Web Token e, portanto, queremos salvá-lo na variável de

162
00:09:51,540 --> 00:09:52,890
‫ambiente, assim como

163
00:09:52,890 --> 00:09:54,830
‫fizemos com todos os outros.

164
00:09:54,830 --> 00:09:58,373
‫Então, estou fazendo isso agora, só para não esquecer.

165
00:10:00,550 --> 00:10:04,100
‫Tudo bem, de qualquer maneira, vamos começar basicamente

166
00:10:04,100 --> 00:10:05,690
‫esquecendo a senha.

167
00:10:05,690 --> 00:10:08,620
‫Então, o envio dessa solicitação, que de novo,

168
00:10:08,620 --> 00:10:10,750
‫demora algumas vezes por causa

169
00:10:10,750 --> 00:10:14,947
‫do envio do e-mail, mas vamos lá, vamos agora para o

170
00:10:16,880 --> 00:10:19,463
‫nosso e-mail, que chegou há poucos segundos.

171
00:10:20,670 --> 00:10:24,890
‫Então, é isso, é claro, esse token.

172
00:10:24,890 --> 00:10:29,890
‫Então vamos pegá-lo, copiá-lo e agora voltar para o Postman, vamos

173
00:10:31,060 --> 00:10:34,303
‫utilizá-lo no Reset Password, como a URL.

174
00:10:35,750 --> 00:10:37,253
‫Ok, faz sentido?

175
00:10:38,250 --> 00:10:41,603
‫Então, novamente, estamos enviando esse token direto no URL.

176
00:10:43,600 --> 00:10:45,730
‫Então aqui, vamos especificar o

177
00:10:45,730 --> 00:10:49,453
‫corpo, porque agora, precisamos realmente especificar nossa nova senha.

178
00:10:53,720 --> 00:10:57,843
‫Então senha e digamos newpass.

179
00:11:01,650 --> 00:11:03,050
‫E então...

180
00:11:05,950 --> 00:11:07,450
‫E aqui vamos chamá-lo de

181
00:11:07,450 --> 00:11:10,263
‫outra coisa, porque, por enquanto, na verdade, quero ver um erro.

182
00:11:11,480 --> 00:11:14,727
‫E, claro, isso é chamado de passwordConfirm.

183
00:11:17,360 --> 00:11:20,393
‫Então, vamos ver o que acontece quando tentamos fazer isso.

184
00:11:23,240 --> 00:11:27,080
‫Vamos esperar, e obteremos uma senha menor que

185
00:11:27,080 --> 00:11:29,640
‫o comprimento mínimo permitido.

186
00:11:29,640 --> 00:11:34,480
‫Ok, então vamos mudar isso, 123, e aqui vamos dizer 1234.

187
00:11:36,090 --> 00:11:37,740
‫Então, eu quero que eles sejam diferentes.

188
00:11:37,740 --> 00:11:40,630
‫Mas você vê que a validação aqui funcionou bem,

189
00:11:40,630 --> 00:11:43,273
‫mesmo ao atualizar a senha com salvar.

190
00:11:45,610 --> 00:11:48,800
‫Então, e agora temos as senhas não são as mesmas!

191
00:11:48,800 --> 00:11:50,960
‫Então, novamente, isso é um erro de validação.

192
00:11:50,960 --> 00:11:53,430
‫E lembre-se, na verdade, que esta é a

193
00:11:53,430 --> 00:11:56,213
‫razão pela qual precisamos usar o save e não update.

194
00:11:57,206 --> 00:11:59,090
‫Então antes, para os

195
00:11:59,090 --> 00:12:03,220
‫tours de atualização, costumávamos usar findOneAndUpdate, mas agora, para tudo

196
00:12:03,220 --> 00:12:06,820
‫relacionado a senhas e ao usuário, sempre usamos

197
00:12:06,820 --> 00:12:10,110
‫save, pois queremos sempre rodar todos os validadores,

198
00:12:10,110 --> 00:12:12,580
‫e acima de tudo, as funções

199
00:12:12,580 --> 00:12:14,450
‫de middleware save.

200
00:12:14,450 --> 00:12:18,293
‫Assim, por exemplo, aqueles em que as senhas são criptografadas.

201
00:12:20,400 --> 00:12:21,610
‫Então, vamos acabar com isso agora.

202
00:12:21,610 --> 00:12:25,030
‫Oh, eu realmente não corrigi, desculpe por isso.

203
00:12:25,030 --> 00:12:28,230
‫E agora deve realmente funcionar.

204
00:12:28,230 --> 00:12:32,870
‫E, de fato, obtemos sucesso e recebemos um novo token.

205
00:12:32,870 --> 00:12:36,600
‫Ótimo, vamos ver se esse token é realmente válido.

206
00:12:36,600 --> 00:12:40,973
‫Então, se pudermos, obtenha todos os tours usando esse token totalmente novo.

207
00:12:43,870 --> 00:12:46,210
‫E aqui vamos nós.

208
00:12:46,210 --> 00:12:51,000
‫Portanto, nosso novo token realmente funciona, e agora para este usuário,

209
00:12:51,000 --> 00:12:53,990
‫para hello @ jonas, essas duas

210
00:12:53,990 --> 00:12:56,190
‫propriedades devem ter desaparecido.

211
00:12:56,190 --> 00:12:59,760
‫Então a senha expira e o token deve ter sumido,

212
00:12:59,760 --> 00:13:03,550
‫já que, bem, já que foi isso que fizemos em nosso código.

213
00:13:03,550 --> 00:13:06,760
‫E então, sim, eles não estão mais aqui.

214
00:13:06,760 --> 00:13:10,210
‫Agora, na verdade, tudo o que precisamos fazer é esta etapa que

215
00:13:10,210 --> 00:13:12,690
‫falta aqui, que é atualizar a propriedade passwordAt para

216
00:13:13,610 --> 00:13:14,773
‫este usuário atual.

217
00:13:15,680 --> 00:13:17,260
‫Mas isso não

218
00:13:17,260 --> 00:13:20,690
‫deve ser tão difícil, então vamos voltar rapidamente

219
00:13:20,690 --> 00:13:24,550
‫ao userModel, que é onde faremos isso usando middleware.

220
00:13:24,550 --> 00:13:26,800
‫E vamos realmente colocar todo o

221
00:13:26,800 --> 00:13:29,023
‫middleware junto aqui no topo.

222
00:13:32,241 --> 00:13:35,408
‫Então, userSchema. pre e novamente

223
00:13:38,830 --> 00:13:42,763
‫ponto save e, em seguida, uma função com next.

224
00:13:44,850 --> 00:13:47,010
‫Novamente, esta função aqui será

225
00:13:47,010 --> 00:13:50,890
‫executada logo antes de um novo documento ser realmente salvo.

226
00:13:50,890 --> 00:13:52,220
‫E, portanto, é

227
00:13:52,220 --> 00:13:54,880
‫o lugar perfeito para realmente especificar essa propriedade.

228
00:13:54,880 --> 00:13:57,480
‫E eu poderia, é claro, ter feito isso em um

229
00:13:58,820 --> 00:14:01,133
‫controlador bem próximo a este código, por exemplo.

230
00:14:02,310 --> 00:14:05,853
‫Mas eu realmente quero que isso aconteça, meio que automaticamente.

231
00:14:06,740 --> 00:14:08,700
‫Então, meio que nos bastidores.

232
00:14:08,700 --> 00:14:11,350
‫Porque mais tarde teremos outro local

233
00:14:11,350 --> 00:14:15,290
‫onde atualizaremos a senha e depois faríamos questão de incluir

234
00:14:15,290 --> 00:14:17,410
‫o mesmo código lá.

235
00:14:17,410 --> 00:14:19,300
‫E assim, de novo, acontece,

236
00:14:19,300 --> 00:14:20,640
‫meio que, nos

237
00:14:20,640 --> 00:14:23,810
‫bastidores, sem que tenhamos que nos preocupar com isso.

238
00:14:23,810 --> 00:14:26,600
‫Agora, quando exatamente queremos

239
00:14:26,600 --> 00:14:30,630
‫definir a propriedade passwordChangedAt como agora?

240
00:14:30,630 --> 00:14:33,450
‫Bem, só queremos quando realmente modificamos a

241
00:14:33,450 --> 00:14:34,660
‫propriedade da senha.

242
00:14:34,660 --> 00:14:37,290
‫E não tenho certeza se usamos esse truque antes,

243
00:14:37,290 --> 00:14:39,660
‫mas de qualquer maneira, vamos usá-lo agora.

244
00:14:39,660 --> 00:14:44,660
‫Então, se não tivermos modificado, então, se não for isso. isModified, assim como este,

245
00:14:47,620 --> 00:14:49,100
‫e então

246
00:14:49,100 --> 00:14:53,070
‫o nome da propriedade, então a senha.

247
00:14:53,070 --> 00:14:56,380
‫Nesse caso, volte imediatamente e execute

248
00:14:57,270 --> 00:14:59,360
‫o próximo middleware.

249
00:14:59,360 --> 00:15:02,823
‫Ok, não assim, mas assim.

250
00:15:04,380 --> 00:15:07,770
‫Então, novamente, se não modificamos a propriedade

251
00:15:07,770 --> 00:15:08,770
‫da

252
00:15:08,770 --> 00:15:12,970
‫senha, bem, é claro, não manipule o passwordChangedAt.

253
00:15:12,970 --> 00:15:15,860
‫Mas que tal criar um novo documento?

254
00:15:15,860 --> 00:15:18,010
‫Bem, quando criamos um novo

255
00:15:18,010 --> 00:15:20,150
‫documento, modificamos a

256
00:15:20,150 --> 00:15:24,350
‫senha de fato e configuramos a propriedade passwordChangedAt, certo?

257
00:15:24,350 --> 00:15:27,260
‫Bem, na implementação atual, realmente o faríamos.

258
00:15:27,260 --> 00:15:29,860
‫Mas há algo mais que podemos usar aqui.

259
00:15:29,860 --> 00:15:32,950
‫Então, basicamente, queremos sair dessa função de

260
00:15:32,950 --> 00:15:36,630
‫middleware imediatamente, se a senha não tiver sido modificada

261
00:15:36,630 --> 00:15:40,274
‫ou se o documento for novo, podemos usar a

262
00:15:40,274 --> 00:15:41,633
‫propriedade isNew.

263
00:15:42,700 --> 00:15:46,210
‫E, novamente, esta é uma daquelas coisas muito boas que

264
00:15:46,210 --> 00:15:48,290
‫você aprende lendo sua documentação.

265
00:15:48,290 --> 00:15:52,010
‫E assim, não posso enfatizar o suficiente o quão importante é realmente

266
00:15:52,010 --> 00:15:55,160
‫ler as documentações quando você precisa de algo que não

267
00:15:55,160 --> 00:15:56,870
‫consegue encontrar em lugar nenhum.

268
00:15:56,870 --> 00:15:59,010
‫Porque, realmente há tantas coisas

269
00:15:59,010 --> 00:16:02,983
‫lá que são completamente impossíveis de ensinar em um curso.

270
00:16:04,810 --> 00:16:08,500
‫De qualquer forma, se o código passar nessa verificação

271
00:16:08,500 --> 00:16:10,830
‫aqui, bem, então vamos simplesmente

272
00:16:10,830 --> 00:16:14,217
‫dizer isso. passwordChangedAt = Data. agora.

273
00:16:18,660 --> 00:16:22,303
‫E então, ligamos em seguida.

274
00:16:23,640 --> 00:16:26,300
‫Bem, em teoria, isso deveria funcionar bem, mas,

275
00:16:26,300 --> 00:16:27,590
‫na verdade, na

276
00:16:27,590 --> 00:16:30,160
‫prática, às vezes acontece um pequeno problema.

277
00:16:30,160 --> 00:16:33,580
‫E esse problema é que às vezes salvar no banco de

278
00:16:33,580 --> 00:16:37,440
‫dados é um pouco mais lento do que emitir o JSON Web

279
00:16:37,440 --> 00:16:40,460
‫Token, fazendo com que o timestamp da senha alterada

280
00:16:40,460 --> 00:16:42,560
‫às vezes seja definido um pouco

281
00:16:42,560 --> 00:16:45,280
‫depois que o JSON Web Token foi criado.

282
00:16:45,280 --> 00:16:48,000
‫E isso fará com que o

283
00:16:48,000 --> 00:16:51,120
‫usuário não consiga fazer login usando o novo token.

284
00:16:51,120 --> 00:16:54,570
‫Porque, lembre-se, todo o motivo pelo qual esse carimbo de data /

285
00:16:54,570 --> 00:16:57,660
‫hora aqui realmente existe é para que possamos compará-lo

286
00:16:57,660 --> 00:17:01,200
‫com o carimbo de data / hora no JSON Web Token, certo?

287
00:17:01,200 --> 00:17:04,353
‫Então, só para lembrar, é,

288
00:17:05,930 --> 00:17:10,930
‫bem, bem aqui, onde verificamos se o usuário alterou a

289
00:17:11,560 --> 00:17:15,170
‫senha depois que o token foi emitido.

290
00:17:15,170 --> 00:17:18,920
‫E então, aqui embaixo, onde criamos este novo token

291
00:17:18,920 --> 00:17:21,010
‫na senha de redefinição.

292
00:17:21,010 --> 00:17:24,170
‫Então, bem aqui, lembre-se, criamos esse novo token

293
00:17:24,170 --> 00:17:27,770
‫e, novamente, às vezes acontece que esse token é criado

294
00:17:27,770 --> 00:17:31,500
‫um pouco antes de o carimbo de data / hora da

295
00:17:31,500 --> 00:17:33,960
‫senha alterada ter sido realmente criado.

296
00:17:33,960 --> 00:17:38,960
‫E então, só precisamos corrigir isso subtraindo um segundo.

297
00:17:39,610 --> 00:17:42,733
‫Então, basicamente, mil milissegundos.

298
00:17:43,750 --> 00:17:47,670
‫E então isso vai colocar a passwordChangedAt um segundo no

299
00:17:47,670 --> 00:17:50,840
‫passado, ok, que então é claro, não

300
00:17:50,840 --> 00:17:54,500
‫será 100% precisa, mas isso não é problema nenhum,

301
00:17:54,500 --> 00:17:58,000
‫porque um segundo aqui não faz diferença nenhuma.

302
00:17:58,000 --> 00:18:01,213
‫É um pequeno hack, mas, novamente, não é problema.

303
00:18:02,190 --> 00:18:06,190
‫Portanto, colocar esse passwordChanged um segundo no passado, garantirá

304
00:18:06,190 --> 00:18:08,920
‫que o token seja sempre criado

305
00:18:08,920 --> 00:18:11,433
‫após a alteração da senha.

306
00:18:13,290 --> 00:18:15,800
‫Então, isso funciona agora, mas

307
00:18:15,800 --> 00:18:18,380
‫como sempre, também vamos testá-lo rapidamente.

308
00:18:18,380 --> 00:18:21,060
‫Ok, então de volta ao Postman.

309
00:18:21,060 --> 00:18:23,990
‫Vamos fazer uma nova redefinição de senha ou, na

310
00:18:23,990 --> 00:18:26,060
‫verdade, não era isso que eu

311
00:18:26,060 --> 00:18:28,400
‫queria, mas é ótimo ver que o

312
00:18:28,400 --> 00:18:30,200
‫código está realmente funcionando.

313
00:18:30,200 --> 00:18:33,610
‫Portanto, o token é inválido ou expirou, e isso

314
00:18:33,610 --> 00:18:35,999
‫porque, bem, 10 minutos se

315
00:18:35,999 --> 00:18:38,640
‫passaram desde que realmente criei esse token.

316
00:18:38,640 --> 00:18:41,240
‫E acho que ainda não tínhamos

317
00:18:41,240 --> 00:18:45,043
‫testado isso, então é ótimo que agora, acidentalmente, realmente tenha feito.

318
00:18:46,370 --> 00:18:50,160
‫Então, novamente, isso vem, caso você esteja se perguntando o que

319
00:18:50,160 --> 00:18:51,493
‫diabos aconteceu, então

320
00:18:53,840 --> 00:18:56,500
‫essa é, obviamente, esta mensagem de erro aqui.

321
00:18:56,500 --> 00:18:59,450
‫E isso significa que não encontrou nenhum usuário

322
00:18:59,450 --> 00:19:03,216
‫que tenha este token ou que tenha um token com mais

323
00:19:03,216 --> 00:19:05,163
‫de 10 minutos no passado.

324
00:19:06,600 --> 00:19:10,393
‫E então, de fato o que eu queria fazer, era esquecer a senha.

325
00:19:12,700 --> 00:19:14,073
‫Então, vamos esperar.

326
00:19:18,000 --> 00:19:19,980
‫Portanto, 8. 6 segundos, mas

327
00:19:19,980 --> 00:19:22,820
‫isso pode ser por causa da minha conexão com a internet.

328
00:19:22,820 --> 00:19:24,520
‫Portanto, se você executar isso em

329
00:19:24,520 --> 00:19:26,373
‫um servidor, provavelmente será muito mais rápido.

330
00:19:27,440 --> 00:19:31,900
‫Vamos pegar isso aqui, de volta ao Postman, e agora

331
00:19:31,900 --> 00:19:36,740
‫redefinimos a senha, novamente com essa senha, realmente não importa se

332
00:19:36,740 --> 00:19:39,823
‫é a mesma que a antiga.

333
00:19:40,690 --> 00:19:43,580
‫E agora temos nosso sucesso aqui.

334
00:19:43,580 --> 00:19:45,193
‫E agora de volta ao Compass.

335
00:19:46,680 --> 00:19:51,210
‫Vamos recarregar e, de fato, obteremos passwordChangedAt.

336
00:19:51,210 --> 00:19:53,290
‫E isso é realmente agora.

337
00:19:53,290 --> 00:19:57,220
‫E então, se agora tentássemos realmente usar esse token, por exemplo,

338
00:19:57,220 --> 00:19:59,870
‫para acessar essa rota protegida, bem, então isso

339
00:19:59,870 --> 00:20:02,130
‫deve funcionar por causa daquela

340
00:20:02,130 --> 00:20:04,633
‫pequena tag de um segundo que fizemos.

341
00:20:06,090 --> 00:20:10,205
‫Então, funcionou e assim, na verdade, agora concluímos nossa

342
00:20:10,205 --> 00:20:12,840
‫funcionalidade de redefinição de senha.

343
00:20:12,840 --> 00:20:16,400
‫Então isso foi um pouco de código, mas é claro,

344
00:20:16,400 --> 00:20:18,100
‫vale totalmente a pena.

345
00:20:18,100 --> 00:20:20,470
‫Portanto, você deve sempre oferecer

346
00:20:20,470 --> 00:20:22,874
‫esta funcionalidade em sua aplicação web,

347
00:20:22,874 --> 00:20:26,750
‫pois caso contrário, um usuário que esquece sua senha fica completamente

348
00:20:26,750 --> 00:20:29,140
‫enroscado, não pode mais usar sua

349
00:20:29,140 --> 00:20:31,940
‫aplicação e, portanto, isso é uma prática terrível.

350
00:20:31,940 --> 00:20:34,020
‫De qualquer forma, isso

351
00:20:34,020 --> 00:20:38,520
‫termina, já, a parte de autenticação e autorização desta seção.

352
00:20:38,520 --> 00:20:40,510
‫Então, novamente, está bem completo

353
00:20:40,510 --> 00:20:43,250
‫e eu me diverti muito implementando isso.

354
00:20:43,250 --> 00:20:46,341
‫Portanto, esta parte para mim é onde os aplicativos da

355
00:20:46,341 --> 00:20:48,560
‫web realmente começam a ganhar vida.

356
00:20:48,560 --> 00:20:51,280
‫Eu sei que não é realmente visível neste ponto,

357
00:20:51,280 --> 00:20:54,280
‫com todos esses, apenas tokens e tokens de cópia

358
00:20:54,280 --> 00:20:56,300
‫e colá-los em outro lugar.

359
00:20:56,300 --> 00:20:59,630
‫Essa não é a ideia usual que temos de fazer

360
00:20:59,630 --> 00:21:02,410
‫login, eu sei, mas é claro de novo,

361
00:21:02,410 --> 00:21:05,430
‫um pouco mais tarde, quando finalmente começarmos a construir

362
00:21:05,430 --> 00:21:06,580
‫o site dinâmico,

363
00:21:06,580 --> 00:21:09,220
‫então, é claro, continuaremos usando essa autenticação

364
00:21:09,220 --> 00:21:13,350
‫que acabamos de construir e então também se tornará visual nesse site dinâmico.

365
00:21:13,350 --> 00:21:16,833
‫Em seguida, implementaremos a funcionalidade de atualização

366
00:21:16,833 --> 00:21:19,620
‫e exclusão do usuário

367
00:21:19,620 --> 00:21:22,990
‫e, em seguida, falaremos também sobre segurança.

368
00:21:22,990 --> 00:21:25,800
‫Isso é o que vem pela frente para o resto

369
00:21:25,800 --> 00:21:28,323
‫da seção, então certifique-se de não perder isso.