1
00:00:01,140 --> 00:00:03,050
‫Jonas: Vamos agora continuar escrevendo nossa

2
00:00:03,050 --> 00:00:04,773
‫função de proteção de middleware.

3
00:00:06,420 --> 00:00:08,910
‫Portanto, na última aula, lemos o

4
00:00:08,910 --> 00:00:10,990
‫token do cabeçalho de autorização

5
00:00:10,990 --> 00:00:14,080
‫e depois verificamos se o token realmente existe.

6
00:00:14,080 --> 00:00:15,023
‫Bem aqui.

7
00:00:15,880 --> 00:00:19,890
‫E a seguir, temos a etapa de verificação do token.

8
00:00:19,890 --> 00:00:21,880
‫E espero que você lembre

9
00:00:21,880 --> 00:00:24,520
‫que nesta etapa, verificamos se alguém manipulou

10
00:00:24,520 --> 00:00:27,500
‫os dados ou também se o token já expirou.

11
00:00:27,500 --> 00:00:31,840
‫Então, já usamos, do pacote de tokens da Web JSON, a função de

12
00:00:31,840 --> 00:00:33,180
‫função de atribuição,

13
00:00:33,180 --> 00:00:35,623
‫e agora vamos usar a função de verificação.

14
00:00:36,820 --> 00:00:39,333
‫Assim como antes, jwt. verifique, e aí,

15
00:00:43,000 --> 00:00:46,630
‫como você pode imaginar, passamos o token para que o algoritmo

16
00:00:46,630 --> 00:00:49,160
‫possa ler a carga útil e, em seguida,

17
00:00:49,160 --> 00:00:52,133
‫lembre-se de que essa etapa também precisa do segredo.

18
00:00:53,250 --> 00:00:56,870
‫Então, basicamente, a fim de criar a assinatura de teste.

19
00:00:56,870 --> 00:01:00,743
‫Então, esse segredo é o processo. env. JWT_SECRET.

20
00:01:03,470 --> 00:01:04,610
‫Lembre-se disso?

21
00:01:04,610 --> 00:01:05,860
‫Agora, como um terceiro

22
00:01:05,860 --> 00:01:09,003
‫argumento, essa função realmente requer uma função de retorno de chamada.

23
00:01:10,090 --> 00:01:12,180
‫Portanto, esse retorno de chamada

24
00:01:12,180 --> 00:01:14,850
‫será executado assim que a verificação for concluída.

25
00:01:14,850 --> 00:01:16,840
‫Então você vê que esta

26
00:01:16,840 --> 00:01:19,564
‫verificação aqui é na verdade uma função assíncrona.

27
00:01:19,564 --> 00:01:22,540
‫Assim, ele verificará um token e, depois disso,

28
00:01:22,540 --> 00:01:23,620
‫quando terminar,

29
00:01:23,620 --> 00:01:27,040
‫chamará a função de retorno de chamada que podemos especificar.

30
00:01:27,040 --> 00:01:29,910
‫Bem, trabalhamos com promessas o tempo

31
00:01:29,910 --> 00:01:33,159
‫todo e não quero quebrar esse padrão aqui.

32
00:01:33,159 --> 00:01:37,000
‫E assim, vamos realmente prometendo essa função.

33
00:01:37,000 --> 00:01:40,370
‫Então, basicamente, para fazer com que ele retorne uma promessa.

34
00:01:40,370 --> 00:01:42,660
‫E, dessa forma, podemos usar async

35
00:01:42,660 --> 00:01:45,613
‫await como qualquer outra função assíncrona que estamos usando.

36
00:01:46,820 --> 00:01:48,050
‫Portanto, para fazer

37
00:01:48,050 --> 00:01:51,050
‫isso, o Node realmente tem uma função promisify integrada.

38
00:01:51,050 --> 00:01:53,650
‫Tudo o que precisamos fazer para

39
00:01:53,650 --> 00:01:56,663
‫usá-lo é exigir o módulo utilitário integrado.

40
00:01:58,695 --> 00:02:00,895
‫Então, vamos fazer isso no topo, na verdade.

41
00:02:02,900 --> 00:02:07,900
‫Então isso vai criar um objeto chamado util, require ...

42
00:02:10,740 --> 00:02:13,400
‫Tudo bem, então isso significa utilidade.

43
00:02:13,400 --> 00:02:15,420
‫Não era isso que eu queria.

44
00:02:15,420 --> 00:02:16,960
‫Então isso significa utilidade.

45
00:02:16,960 --> 00:02:20,300
‫E então vamos usar o método promisify.

46
00:02:20,300 --> 00:02:22,900
‫Mas, uma vez que usaremos apenas esse método, podemos realmente

47
00:02:22,900 --> 00:02:24,603
‫fazer isso com mais facilidade.

48
00:02:25,578 --> 00:02:26,990
‫Portanto, em vez

49
00:02:26,990 --> 00:02:30,610
‫de fazer isso, podemos simplesmente desestruturar esse objeto e receber

50
00:02:30,610 --> 00:02:32,823
‫a promessa diretamente a partir daí.

51
00:02:35,388 --> 00:02:38,453
‫Então, novamente, isso é apenas usar a desestruturação ES6.

52
00:02:41,182 --> 00:02:43,230
‫Ok, agora é muito fácil de usar.

53
00:02:43,230 --> 00:02:46,127
‫Tudo o que temos a fazer é chamar promisify.

54
00:02:47,434 --> 00:02:51,463
‫Portanto, prometam e, em seguida, passem a função lá.

55
00:02:53,500 --> 00:02:56,080
‫E agora, tudo isso aqui é uma

56
00:02:56,080 --> 00:02:56,970
‫função que

57
00:02:56,970 --> 00:02:59,190
‫precisamos chamar, que retornará uma promessa.

58
00:02:59,190 --> 00:03:01,810
‫Então aqui, nós realmente chamamos a função.

59
00:03:01,810 --> 00:03:03,900
‫E isso irá retornar uma

60
00:03:03,900 --> 00:03:08,300
‫promessa, então podemos aguardar e armazenar o resultado em uma variável.

61
00:03:08,300 --> 00:03:10,390
‫Portanto, o valor do resultado da promessa

62
00:03:10,390 --> 00:03:12,350
‫será, na verdade, os dados

63
00:03:12,350 --> 00:03:15,823
‫decodificados, ou seja, a carga útil decodificada desse token da Web JSON.

64
00:03:17,600 --> 00:03:19,360
‫Deixe-me chamá-lo de decodificado aqui.

65
00:03:19,360 --> 00:03:20,193
‫Tudo bem.

66
00:03:20,193 --> 00:03:23,490
‫E podemos esperar, porque na verdade já dissemos que

67
00:03:23,490 --> 00:03:25,453
‫é uma função assíncrona.

68
00:03:27,670 --> 00:03:30,850
‫E agora, só para ver se realmente

69
00:03:30,850 --> 00:03:34,730
‫funciona, vamos registrar esses dados decodificados no console também.

70
00:03:34,730 --> 00:03:38,143
‫E, na verdade, podemos remover este console. faça logoff do token.

71
00:03:39,050 --> 00:03:40,400
‫Aquele de que não precisamos mais.

72
00:03:42,140 --> 00:03:46,560
‫Então, vamos tentar enviar essa solicitação novamente, sim, mas desta

73
00:03:46,560 --> 00:03:49,990
‫vez ativando esse cabeçalho de autorização

74
00:03:49,990 --> 00:03:54,850
‫para enviarmos um token da Web JSON junto com a solicitação.

75
00:03:54,850 --> 00:03:55,940
‫Então foi isso que enviou.

76
00:03:55,940 --> 00:03:58,540
‫E agora, de fato, temos acesso

77
00:03:58,540 --> 00:04:02,070
‫aos dados e, portanto, agora temos acesso à rota protegida.

78
00:04:02,070 --> 00:04:02,903
‫OK?

79
00:04:02,903 --> 00:04:06,203
‫Mas o que eu queria ver é esse objeto decodificado aqui.

80
00:04:07,230 --> 00:04:09,910
‫E então este aqui deve ser o ID do usuário.

81
00:04:09,910 --> 00:04:12,530
‫Então, vamos dar uma olhada nisso no Postman novamente.

82
00:04:12,530 --> 00:04:13,423
‫Portanto, 62a42.

83
00:04:15,520 --> 00:04:18,740
‫E então, de fato, bem, onde temos isso?

84
00:04:18,740 --> 00:04:20,193
‫Vamos dar uma olhada no Compass.

85
00:04:21,240 --> 00:04:24,813
‫E, de fato, o ID desse usuário é 62a42.

86
00:04:27,160 --> 00:04:29,347
‫E isso significa que realmente temos

87
00:04:29,347 --> 00:04:31,340
‫nossa carga útil correta aqui.

88
00:04:31,340 --> 00:04:33,420
‫Então, basicamente, o ID de usuário correto.

89
00:04:33,420 --> 00:04:36,460
‫Então, também temos o carimbo de data / hora da

90
00:04:36,460 --> 00:04:39,500
‫data de criação e da data de expiração do token.

91
00:04:39,500 --> 00:04:40,700
‫Então está funcionando.

92
00:04:40,700 --> 00:04:43,710
‫Mas agora vamos realmente tentar manipular a carga útil

93
00:04:43,710 --> 00:04:44,563
‫desse token.

94
00:04:47,088 --> 00:04:49,090
‫Então, vamos copiá-lo aqui novamente.

95
00:04:49,090 --> 00:04:52,443
‫Mas então vou para o depurador JWT.

96
00:04:54,640 --> 00:04:57,023
‫Então, novamente, em jwt. Io.

97
00:05:00,290 --> 00:05:02,363
‫Então, vamos tirar isso.

98
00:05:03,310 --> 00:05:06,010
‫E agora o que vou fazer é alterar alguns

99
00:05:06,010 --> 00:05:09,260
‫dados aqui e isso mudará o token codificado aqui, que posso

100
00:05:09,260 --> 00:05:11,010
‫seguir em frente e copiar.

101
00:05:12,420 --> 00:05:14,693
‫Então, vamos simplesmente substituir, na

102
00:05:15,580 --> 00:05:19,050
‫verdade, vou apenas substituir esses dois números aqui

103
00:05:19,050 --> 00:05:20,940
‫por algo diferente.

104
00:05:20,940 --> 00:05:23,590
‫E então, como você pode ver, isso mudou o token aqui.

105
00:05:23,590 --> 00:05:26,040
‫E agora, tentarei obter acesso a

106
00:05:26,040 --> 00:05:27,470
‫essa rota protegida

107
00:05:27,470 --> 00:05:30,373
‫usando este token da Web JSON manipulado.

108
00:05:31,460 --> 00:05:33,133
‫Ok, faz sentido?

109
00:05:34,100 --> 00:05:37,023
‫Então, só para ver se está funcionando corretamente.

110
00:05:38,632 --> 00:05:39,970
‫Então, estou copiando

111
00:05:39,970 --> 00:05:42,660
‫este aqui agora e colando este outro diferente.

112
00:05:42,660 --> 00:05:47,310
‫E então, se eu enviar esta solicitação, obteremos um erro.

113
00:05:47,310 --> 00:05:48,250
‫Tão bom.

114
00:05:48,250 --> 00:05:50,843
‫Portanto, vemos que o nome do erro é

115
00:05:51,840 --> 00:05:54,220
‫JsonWebTokenError e temos uma assinatura inválida.

116
00:05:54,220 --> 00:05:55,160
‫Tão bom.

117
00:05:55,160 --> 00:05:57,650
‫Isso é exatamente o que estávamos procurando.

118
00:05:57,650 --> 00:06:00,210
‫Portanto, esse é um dos dois erros que podem ocorrer.

119
00:06:00,210 --> 00:06:02,853
‫O outro é que o token já expirou.

120
00:06:04,359 --> 00:06:07,180
‫Este é chamado JsonWebTokenError e, na

121
00:06:07,180 --> 00:06:10,890
‫verdade, vamos prosseguir e lidar com esse erro agora.

122
00:06:10,890 --> 00:06:12,240
‫E a maneira

123
00:06:12,240 --> 00:06:16,470
‫que poderíamos fazer é adicionar um bloco try-catch bem aqui.

124
00:06:16,470 --> 00:06:17,460
‫Direito?

125
00:06:17,460 --> 00:06:19,600
‫Logo depois de fazer esse código,

126
00:06:19,600 --> 00:06:21,510
‫poderíamos introduzir um bloco

127
00:06:21,510 --> 00:06:24,260
‫try e, em seguida, no catch, criaríamos erros

128
00:06:24,260 --> 00:06:26,290
‫que seriam enviados ao cliente.

129
00:06:26,290 --> 00:06:28,070
‫Agora, em vez de fazer

130
00:06:28,070 --> 00:06:30,970
‫dessa forma, eu realmente quero usar nosso middleware de tratamento

131
00:06:30,970 --> 00:06:33,290
‫de erros global para fazer isso por nós.

132
00:06:33,290 --> 00:06:35,850
‫Portanto, não gostamos de lidar com erros aqui mesmo em

133
00:06:35,850 --> 00:06:37,220
‫nossa função de middleware.

134
00:06:37,220 --> 00:06:41,140
‫Em vez disso, geralmente o delegamos ao controlador de erro.

135
00:06:41,140 --> 00:06:43,940
‫E então, vamos fazer exatamente a mesma coisa aqui.

136
00:06:43,940 --> 00:06:46,710
‫Então controlador de erro.

137
00:06:46,710 --> 00:06:48,600
‫E então é exatamente a mesma

138
00:06:48,600 --> 00:06:50,930
‫coisa que temos com nossos outros erros aqui.

139
00:06:50,930 --> 00:06:54,210
‫Por exemplo, o erro de validação vindo do Mongoose,

140
00:06:54,210 --> 00:06:55,670
‫então de outra biblioteca.

141
00:06:55,670 --> 00:06:59,060
‫E agora, esse erro está realmente vindo de outra

142
00:06:59,060 --> 00:07:02,180
‫biblioteca e também tem seu próprio nome.

143
00:07:02,180 --> 00:07:03,470
‫Então vamos ver isso.

144
00:07:03,470 --> 00:07:04,820
‫E é JsonWebTokenError.

145
00:07:06,900 --> 00:07:07,940
‫Tudo bem.

146
00:07:07,940 --> 00:07:09,923
‫E então, vamos fazer muito semelhante aqui.

147
00:07:11,850 --> 00:07:12,683
‫Então se. nome é

148
00:07:15,477 --> 00:07:19,310
‫este, então o erro deve ser igual a manipular o erro.

149
00:07:19,310 --> 00:07:23,463
‫OK.

150
00:07:27,010 --> 00:07:27,843
‫Portanto, vamos prosseguir

151
00:07:27,843 --> 00:07:30,430
‫e criar esta função, na verdade, em algum lugar aqui.

152
00:07:30,430 --> 00:07:31,953
‫E este é extremamente simples.

153
00:07:35,782 --> 00:07:37,810
‫Tudo o que ele faz é pegar um

154
00:07:37,810 --> 00:07:39,760
‫erro e retornar um novo AppError.

155
00:07:39,760 --> 00:07:41,433
‫OK?

156
00:07:44,480 --> 00:07:45,320
‫Portanto, nesta

157
00:07:45,320 --> 00:07:48,950
‫função de seta ES6, como espero que você saiba, podemos escrever essas

158
00:07:48,950 --> 00:07:50,790
‫linhas simples onde não precisamos

159
00:07:50,790 --> 00:07:53,610
‫nem especificar as chaves e nem a palavra-chave return.

160
00:07:53,610 --> 00:07:55,610
‫Portanto, isso retornará automática

161
00:07:55,610 --> 00:07:58,670
‫e implicitamente tudo o que colocarmos aqui.

162
00:07:58,670 --> 00:08:00,123
‫Direito?

163
00:08:01,010 --> 00:08:01,843
‫E

164
00:08:01,843 --> 00:08:04,763
‫então, o que queremos dizer aqui é simplesmente, token

165
00:08:05,980 --> 00:08:07,273
‫inválido, faça login novamente.

166
00:08:09,580 --> 00:08:12,640
‫E então, o código de erro, como antes,

167
00:08:12,640 --> 00:08:15,000
‫é um 401 para não autorizado.

168
00:08:15,000 --> 00:08:17,463
‫Agora, isso só funciona, lembre-se, na produção.

169
00:08:19,497 --> 00:08:22,410
‫E então, se fizéssemos isso agora de novo,

170
00:08:22,410 --> 00:08:24,883
‫obteríamos exatamente a mesma coisa.

171
00:08:24,883 --> 00:08:27,730
‫E então, vamos voltar aqui e

172
00:08:27,730 --> 00:08:29,890
‫executar isso na produção.

173
00:08:29,890 --> 00:08:32,340
‫Então npm run start: production.

174
00:08:32,340 --> 00:08:37,340
‫Sim, assim mesmo.

175
00:08:39,470 --> 00:08:40,733
‫Portanto, se tentarmos

176
00:08:41,650 --> 00:08:43,890
‫novamente, vamos ver se obtemos nosso erro.

177
00:08:43,890 --> 00:08:45,630
‫E, de fato, nós fazemos.

178
00:08:45,630 --> 00:08:47,840
‫Portanto, se, agora, um usuário em produção

179
00:08:47,840 --> 00:08:50,040
‫tentar acessar nosso aplicativo com um

180
00:08:50,040 --> 00:08:52,930
‫token inválido, bem, ele receberá apenas esta mensagem de erro.

181
00:08:52,930 --> 00:08:55,890
‫Tudo bem?

182
00:08:55,890 --> 00:08:57,120
‫Portanto, esse é o primeiro erro que podemos obter.

183
00:08:57,120 --> 00:08:59,920
‫Mas outra é que o usuário tenta

184
00:08:59,920 --> 00:09:01,560
‫acessar o aplicativo

185
00:09:01,560 --> 00:09:03,500
‫com um token já expirado.

186
00:09:03,500 --> 00:09:06,147
‫E então, agora vamos tentar criar esse erro.

187
00:09:06,147 --> 00:09:08,733
‫E para fazer isso, alterarei

188
00:09:09,683 --> 00:09:13,080
‫o tempo que leva para o token expirar.

189
00:09:13,080 --> 00:09:14,943
‫Portanto, agora, temos 90 dias.

190
00:09:17,811 --> 00:09:19,190
‫Vamos colocar em, tipo, cinco segundos.

191
00:09:19,190 --> 00:09:22,183
‫OK.

192
00:09:23,078 --> 00:09:23,911
‫Dê uma chance.

193
00:09:23,911 --> 00:09:24,870
‫E agora tente fazer o login novamente.

194
00:09:24,870 --> 00:09:26,823
‫Então, vamos salvar este aqui também.

195
00:09:28,090 --> 00:09:30,943
‫Então, entre em usuários e, em seguida, faça login.

196
00:09:32,920 --> 00:09:37,043
‫Assim, podemos fazer login e isso nos dará um novo token,

197
00:09:39,060 --> 00:09:43,100
‫mas esse token só é válido por cinco segundos.

198
00:09:43,100 --> 00:09:46,100
‫E então, esses cinco segundos deveriam ter passado neste ponto.

199
00:09:46,100 --> 00:09:49,550
‫Portanto, agora copiarei esse token e tentarei acessar nossa

200
00:09:49,550 --> 00:09:51,690
‫rota protegida usando esse token.

201
00:09:51,690 --> 00:09:55,713
‫Então cole aqui.

202
00:09:58,529 --> 00:09:59,362
‫E agora, vamos ver o que temos.

203
00:09:59,362 --> 00:10:01,630
‫E, na verdade, por algum motivo, funcionou.

204
00:10:01,630 --> 00:10:04,280
‫Então, vamos dar uma olhada em nosso depurador JWT novamente.

205
00:10:04,280 --> 00:10:08,593
‫E diz, criado em 2 de maio, mas expira

206
00:10:11,620 --> 00:10:14,160
‫apenas em 31 de julho.

207
00:10:14,160 --> 00:10:16,720
‫Então, algo deu errado na criação do token, eu acho.

208
00:10:16,720 --> 00:10:21,023
‫E então, vamos mudar isso aqui novamente.

209
00:10:22,140 --> 00:10:23,810
‫E vou colocar cinco aqui.

210
00:10:23,810 --> 00:10:25,993
‫E então, esse cinco deve

211
00:10:27,270 --> 00:10:30,340
‫representar cinco milissegundos, ou posso até, tipo, colocar

212
00:10:30,340 --> 00:10:32,630
‫5000, que deve ser cinco segundos.

213
00:10:32,630 --> 00:10:34,733
‫OK.

214
00:10:37,680 --> 00:10:38,890
‫Deixe-me salvá-lo novamente para reiniciar o servidor.

215
00:10:38,890 --> 00:10:42,363
‫Tente de novo.

216
00:10:43,240 --> 00:10:44,570
‫Então, faça login novamente aqui.

217
00:10:44,570 --> 00:10:46,113
‫Tudo bem.

218
00:10:47,680 --> 00:10:48,600
‫Agora, tudo o

219
00:10:48,600 --> 00:10:52,930
‫que precisamos fazer é basicamente esperar cinco segundos, e esse tempo já deve ter passado neste ponto.

220
00:10:52,930 --> 00:10:56,933
‫Cole aqui novamente.

221
00:11:00,230 --> 00:11:01,500
‫E vamos lá.

222
00:11:01,500 --> 00:11:03,560
‫E, de fato, obtemos um erro.

223
00:11:03,560 --> 00:11:05,860
‫Agora lembre-se de

224
00:11:05,860 --> 00:11:09,850
‫que esse é basicamente o erro padrão que

225
00:11:09,850 --> 00:11:13,230
‫obtemos caso não o tratemos corretamente.

226
00:11:13,230 --> 00:11:14,700
‫Direito?

227
00:11:14,700 --> 00:11:15,750
‫Então, vamos dar uma olhada no erro.

228
00:11:15,750 --> 00:11:18,840
‫E, na verdade, temos aqui no console.

229
00:11:18,840 --> 00:11:21,350
‫Então, vamos ver de onde vem isso.

230
00:11:21,350 --> 00:11:24,620
‫E sim, vem deste lugar.

231
00:11:24,620 --> 00:11:26,673
‫Portanto, este é o caso em que temos um erro desconhecido.

232
00:11:27,760 --> 00:11:31,690
‫Lembre-se, portanto, um erro que não está marcado

233
00:11:31,690 --> 00:11:34,090
‫como um erro operacional e,

234
00:11:34,090 --> 00:11:35,640
‫portanto, queremos registrá-lo.

235
00:11:35,640 --> 00:11:37,543
‫Então, nós registramos aqui e enviamos

236
00:11:38,500 --> 00:11:39,650
‫essa mensagem de erro

237
00:11:39,650 --> 00:11:42,150
‫genérica para o cliente, aquela que acabamos de

238
00:11:42,150 --> 00:11:43,270
‫ver no Postman.

239
00:11:43,270 --> 00:11:45,610
‫Mas aqui temos os detalhes desse erro.

240
00:11:45,610 --> 00:11:48,100
‫E então, este tem o nome de TokenExpiredError.

241
00:11:48,100 --> 00:11:51,480
‫Tudo bem.

242
00:11:51,480 --> 00:11:52,313
‫E então, agora vamos lidar com isso também.

243
00:11:52,313 --> 00:11:55,360
‫Portanto, estou copiando agora e, em seguida, crio apenas

244
00:11:55,360 --> 00:11:57,171
‫outro se estiver aqui.

245
00:11:57,171 --> 00:12:02,171
‫Portanto, se o erro. nome é igual a este, bem,

246
00:12:02,300 --> 00:12:07,300
‫digamos, manipule JWTExpiredError

247
00:12:08,980 --> 00:12:10,343
‫com

248
00:12:12,711 --> 00:12:14,461
‫a seta.

249
00:12:18,640 --> 00:12:20,233
‫Vamos copiá-lo e colocá-lo bem aqui.

250
00:12:22,568 --> 00:12:25,750
‫E isso, é claro, é muito semelhante ao anterior.

251
00:12:33,186 --> 00:12:37,770
‫Seu token expirou.

252
00:12:37,770 --> 00:12:40,493
‫Por favor faça login novamente.

253
00:12:43,940 --> 00:12:45,193
‫E novamente, com um código de erro 401.

254
00:12:48,670 --> 00:12:51,423
‫Ok, vamos tentar de novo.

255
00:12:52,360 --> 00:12:54,270
‫E então, essa é exatamente a mensagem de

256
00:12:54,270 --> 00:12:56,043
‫erro que devemos ver agora aqui.

257
00:12:56,043 --> 00:12:58,023
‫Tudo bem.

258
00:12:59,430 --> 00:13:00,263
‫E realmente é.

259
00:13:00,263 --> 00:13:01,263
‫Excelente.

260
00:13:02,480 --> 00:13:03,520
‫Vamos terminar o processo

261
00:13:03,520 --> 00:13:04,980
‫aqui e iniciá-lo no modo dev, é claro.

262
00:13:04,980 --> 00:13:07,560
‫Então npm

263
00:13:07,560 --> 00:13:10,213
‫start, e tudo bem.

264
00:13:11,700 --> 00:13:13,740
‫Então, este, não precisamos mais, então vamos fechá-lo.

265
00:13:13,740 --> 00:13:17,460
‫Ou, na verdade, vamos corrigir esse pequeno erro aqui, porque, na verdade, não

266
00:13:17,460 --> 00:13:19,880
‫usamos esse erro aqui de forma alguma.

267
00:13:19,880 --> 00:13:23,113
‫Então, vamos nos livrar disso.

268
00:13:24,170 --> 00:13:25,423
‫E então aqui embaixo, não precisamos passar lá.

269
00:13:29,260 --> 00:13:32,063
‫Legal.

270
00:13:39,290 --> 00:13:40,123
‫É claro que também precisamos mudar isso de volta para 90 dias.

271
00:13:41,060 --> 00:13:44,423
‫Tudo bem.

272
00:13:47,200 --> 00:13:48,040
‫E

273
00:13:48,040 --> 00:13:51,560
‫então, só para ter certeza, vamos fazer login aqui

274
00:13:51,560 --> 00:13:52,803
‫novamente, copiar o

275
00:13:53,830 --> 00:13:55,513
‫token e colocá-lo aqui.

276
00:13:56,680 --> 00:13:59,050
‫Agora, este processo de copiar o token

277
00:13:59,050 --> 00:14:01,750
‫e depois colá-lo aqui neste cabeçalho pode parecer

278
00:14:01,750 --> 00:14:04,190
‫um pouco estranho e, na verdade, vamos consertar

279
00:14:04,190 --> 00:14:05,640
‫isso em um

280
00:14:05,640 --> 00:14:07,230
‫dos vídeos futuros para que

281
00:14:07,230 --> 00:14:09,030
‫basicamente esse processo aconteça automaticamente.

282
00:14:09,030 --> 00:14:12,070
‫Mas agora, o que é importante é que

283
00:14:12,070 --> 00:14:13,970
‫ele voltou a funcionar.

284
00:14:13,970 --> 00:14:16,750
‫Portanto, podemos realmente nos livrar deste console. faça login aqui e vá para

285
00:14:16,750 --> 00:14:21,027
‫a próxima etapa.

286
00:14:21,027 --> 00:14:24,250
‫E poderíamos realmente parar aqui agora, se quiséssemos.

287
00:14:24,250 --> 00:14:27,010
‫E, novamente, a maioria dos tutoriais que você

288
00:14:27,010 --> 00:14:30,130
‫vai descobrir por aí, na verdade, apenas param por aqui.

289
00:14:30,130 --> 00:14:32,420
‫Mas isso ainda não é seguro o suficiente.

290
00:14:32,420 --> 00:14:35,210
‫Então, por exemplo, e se o usuário tiver

291
00:14:35,210 --> 00:14:37,550
‫sido excluído nesse meio tempo?

292
00:14:37,550 --> 00:14:39,840
‫Portanto, o token ainda existirá, mas se

293
00:14:39,840 --> 00:14:41,800
‫o usuário não existir mais,

294
00:14:41,800 --> 00:14:43,900
‫bem, então não queremos logá-lo, certo?

295
00:14:43,900 --> 00:14:47,780
‫Ou pior ainda, e se o usuário realmente alterou

296
00:14:47,780 --> 00:14:50,070
‫sua senha depois que o

297
00:14:50,070 --> 00:14:52,130
‫token foi emitido?

298
00:14:52,130 --> 00:14:54,360
‫Bem, isso também não deve funcionar, certo?

299
00:14:54,360 --> 00:14:56,950
‫Por exemplo, imagine que alguém

300
00:14:56,950 --> 00:15:00,750
‫roubou o token JSON da web de um usuário.

301
00:15:00,750 --> 00:15:01,870
‫Mas então, para

302
00:15:01,870 --> 00:15:04,380
‫se proteger contra isso, o usuário muda sua senha.

303
00:15:04,380 --> 00:15:06,770
‫E então, é claro, aquele token antigo emitido

304
00:15:06,770 --> 00:15:09,270
‫antes da alteração da senha não deve mais ser válido.

305
00:15:09,270 --> 00:15:12,940
‫Portanto, não deve ser aceito o acesso a rotas protegidas.

306
00:15:12,940 --> 00:15:16,906
‫E então, esse é o tipo de coisa que vamos implementar aqui

307
00:15:16,906 --> 00:15:19,550
‫na etapa três e na etapa quatro.

308
00:15:19,550 --> 00:15:22,060
‫Portanto, a primeira coisa a fazer é verificar se o

309
00:15:22,060 --> 00:15:23,120
‫usuário realmente ainda existe.

310
00:15:23,120 --> 00:15:26,060
‫E então, esse deve ser o mais fácil.

311
00:15:26,060 --> 00:15:28,690
‫Então, digamos apenas, usuário. findById.

312
00:15:28,690 --> 00:15:32,463
‫E então, agora é por isso que

313
00:15:36,568 --> 00:15:38,440
‫realmente temos o ID na

314
00:15:38,440 --> 00:15:40,540
‫carga útil, porque agora podemos usar esse ID

315
00:15:40,540 --> 00:15:42,767
‫e consultar o usuário usando apenas esse ID.

316
00:15:42,767 --> 00:15:46,530
‫Tão decodificado. identificação.

317
00:15:46,530 --> 00:15:49,390
‫Tudo bem?

318
00:15:49,390 --> 00:15:50,223
‫Então, isso deve localizar o novo usuário.

319
00:15:50,223 --> 00:15:53,110
‫E, claro, precisamos aguardar isso e, em

320
00:15:53,110 --> 00:15:55,860
‫seguida, armazená-lo em uma variável.

321
00:15:55,860 --> 00:15:59,560
‫Estou chamando de FreshUser.

322
00:15:59,560 --> 00:16:01,480
‫Tudo bem?

323
00:16:03,148 --> 00:16:03,981
‫Porque não é realmente um novo usuário.

324
00:16:03,981 --> 00:16:05,460
‫É só quando criamos um.

325
00:16:05,460 --> 00:16:07,300
‫Mas este não é realmente um novo, é apenas

326
00:16:07,300 --> 00:16:09,030
‫o usuário com base no ID decodificado.

327
00:16:09,030 --> 00:16:12,980
‫OK?

328
00:16:12,980 --> 00:16:13,870
‫E podemos

329
00:16:13,870 --> 00:16:16,833
‫fazer isso para ter 100% de certeza de que o

330
00:16:16,833 --> 00:16:18,990
‫ID está realmente correto, porque se fizemos

331
00:16:18,990 --> 00:16:22,460
‫isso até este ponto do código aqui, isso significa que o processo

332
00:16:22,460 --> 00:16:25,110
‫de verificação que temos anteriormente, aqui, foi bem-sucedido.

333
00:16:25,110 --> 00:16:28,200
‫Caso contrário, isso causaria um erro

334
00:16:28,200 --> 00:16:30,220
‫que impediria a função

335
00:16:30,220 --> 00:16:31,490
‫de continuar.

336
00:16:31,490 --> 00:16:33,410
‫E então, novamente, este

337
00:16:33,410 --> 00:16:36,660
‫processo de verificação aqui é responsável por verificar

338
00:16:36,660 --> 00:16:38,620
‫se ninguém alterou a ID

339
00:16:38,620 --> 00:16:40,900
‫que está na carga deste token.

340
00:16:40,900 --> 00:16:43,033
‫E então, por causa disso,

341
00:16:43,970 --> 00:16:46,970
‫podemos ter 100% de certeza de que o usuário para

342
00:16:46,970 --> 00:16:50,600
‫o qual emitimos o JWT é exatamente aquele cujo ID está

343
00:16:50,600 --> 00:16:52,790
‫agora dentro da carga decodificada, então este.

344
00:16:52,790 --> 00:16:56,810
‫OK?

345
00:16:56,810 --> 00:16:57,690
‫Portanto, o processo de verificação é realmente fundamental.

346
00:16:57,690 --> 00:17:00,440
‫É realmente o que faz todo esse trabalho.

347
00:17:00,440 --> 00:17:02,440
‫De qualquer forma, agora o que precisamos fazer é

348
00:17:04,730 --> 00:17:06,410
‫verificar se realmente existe um novo usuário.

349
00:17:06,410 --> 00:17:09,570
‫E se não, bem então, é claro, vamos

350
00:17:09,570 --> 00:17:11,570
‫retornar um novo erro.

351
00:17:11,570 --> 00:17:13,844
‫Portanto, se não houver nenhum

352
00:17:13,844 --> 00:17:16,577
‫freshUser, retorne deste middleware e chame o

353
00:17:19,880 --> 00:17:22,100
‫próximo com um erro.

354
00:17:22,100 --> 00:17:24,083
‫Portanto, este é um padrão

355
00:17:24,920 --> 00:17:27,100
‫que temos visto continuamente neste ponto, certo?

356
00:17:27,100 --> 00:17:29,403
‫Portanto, o token não existe

357
00:17:30,350 --> 00:17:31,490
‫mais.

358
00:17:35,470 --> 00:17:39,173
‫E, na verdade, é o contrário.

359
00:17:40,810 --> 00:17:42,750
‫Portanto, na verdade, o

360
00:17:42,750 --> 00:17:45,200
‫usuário pertencente ao token não existe mais.

361
00:17:47,170 --> 00:17:48,680
‫Direito?

362
00:17:48,680 --> 00:17:49,513
‫E então, o 401.

363
00:17:49,513 --> 00:17:51,297
‫OK.

364
00:17:53,780 --> 00:17:54,920
‫Então, vamos testar isso mais uma vez.

365
00:17:54,920 --> 00:17:57,860
‫E vamos criar um novo usuário para isso.

366
00:17:57,860 --> 00:18:00,843
‫Portanto, apenas teste com a mesma senha para que estejamos sempre

367
00:18:02,620 --> 00:18:04,880
‫usando a mesma aqui apenas para tornar o

368
00:18:04,880 --> 00:18:06,590
‫nosso teste um pouco mais fácil.

369
00:18:06,590 --> 00:18:09,160
‫E eu sei que todos esses testes aqui

370
00:18:09,160 --> 00:18:11,070
‫fazem o vídeo levar muito tempo,

371
00:18:11,070 --> 00:18:14,440
‫mas é claro, é muito importante que testemos tudo o que

372
00:18:14,440 --> 00:18:15,900
‫fazemos, especialmente em

373
00:18:15,900 --> 00:18:17,950
‫um tópico tão importante como autenticação.

374
00:18:17,950 --> 00:18:21,713
‫Agora estou usando este JWT aqui, estou

375
00:18:23,071 --> 00:18:27,780
‫colando aqui, mas é claro, antes de enviar a solicitação,

376
00:18:27,780 --> 00:18:30,630
‫irei excluir esse usuário imediatamente.

377
00:18:30,630 --> 00:18:33,573
‫OK?

378
00:18:34,650 --> 00:18:35,690
‫Então, novamente, vamos fingir

379
00:18:35,690 --> 00:18:37,690
‫que alguém criou um usuário e se conectou, e

380
00:18:37,690 --> 00:18:40,020
‫digamos que, depois de algum tempo, o usuário foi excluído.

381
00:18:40,020 --> 00:18:43,500
‫Mas, nesse ínterim, alguém poderia ter obtido acesso a esse

382
00:18:43,500 --> 00:18:44,333
‫JWT

383
00:18:44,333 --> 00:18:47,410
‫e agora poderia tentar fazer login como aquele

384
00:18:47,410 --> 00:18:50,030
‫usuário que, de fato, já foi excluído.

385
00:18:50,030 --> 00:18:52,580
‫E então, novamente, não devemos deixar isso acontecer.

386
00:18:52,580 --> 00:18:55,520
‫Então, deixe-me deletar este usuário aqui agora.

387
00:18:55,520 --> 00:18:57,713
‫E lá vamos nós.

388
00:18:59,010 --> 00:18:59,943
‫E então, vamos testar agora.

389
00:19:01,720 --> 00:19:03,630
‫E, novamente, lembre-se de que o

390
00:19:03,630 --> 00:19:07,060
‫usuário pertencente ao ID que está nesta carga útil não está mais lá.

391
00:19:07,060 --> 00:19:10,690
‫Então vamos ver.

392
00:19:10,690 --> 00:19:12,040
‫E, de fato, recebemos essa mensagem de erro que acabamos de criar.

393
00:19:12,040 --> 00:19:16,313
‫Então esse também está funcionando.

394
00:19:17,520 --> 00:19:20,200
‫E vamos para o último.

395
00:19:20,200 --> 00:19:22,400
‫Portanto, etapa número quatro, verifique se o usuário

396
00:19:22,400 --> 00:19:23,830
‫alterou sua senha recentemente.

397
00:19:23,830 --> 00:19:27,070
‫Então, basicamente, depois que o token foi emitido.

398
00:19:27,070 --> 00:19:30,100
‫E para implementar esse teste, criaremos outro

399
00:19:30,100 --> 00:19:31,550
‫método de instância.

400
00:19:31,550 --> 00:19:34,260
‫Basicamente, um método que

401
00:19:34,260 --> 00:19:37,030
‫estará disponível em todos os documentos.

402
00:19:37,030 --> 00:19:38,330
‫Portanto, os documentos são instâncias de um modelo.

403
00:19:38,330 --> 00:19:41,410
‫Tudo bem?

404
00:19:41,410 --> 00:19:42,243
‫E fazemos isso porque

405
00:19:42,243 --> 00:19:44,490
‫é uma grande quantidade de código que precisamos para esta verificação.

406
00:19:44,490 --> 00:19:46,540
‫E então, na verdade, esse

407
00:19:46,540 --> 00:19:50,040
‫código pertence ao modelo de usuário e não realmente ao controlador.

408
00:19:50,040 --> 00:19:51,970
‫OK?

409
00:19:51,970 --> 00:19:52,803
‫E então, vamos

410
00:19:52,803 --> 00:19:55,050
‫fazer isso exatamente como fizemos antes para verificar a senha.

411
00:19:55,050 --> 00:19:57,270
‫Portanto, no modelo de usuário, já

412
00:19:57,270 --> 00:19:59,840
‫implementamos este método de instância estática correctPassword, lembra?

413
00:19:59,840 --> 00:20:04,710
‫E então, vamos agora criar outro.

414
00:20:04,710 --> 00:20:06,903
‫Então userSchema. métodos. changesPasswordAfter.

415
00:20:08,339 --> 00:20:13,339
‫Então funcione, e para esta função,

416
00:20:22,390 --> 00:20:24,550
‫passaremos o carimbo de data / hora JWT.

417
00:20:24,550 --> 00:20:27,530
‫Então, basicamente, o carimbo de data / hora que

418
00:20:27,530 --> 00:20:29,630
‫diz quando o token foi emitido.

419
00:20:29,630 --> 00:20:32,190
‫Então, vamos chamá-lo de JWTTimestamp.

420
00:20:32,190 --> 00:20:34,437
‫Tudo bem.

421
00:20:40,310 --> 00:20:41,143
‫E, por padrão, retornaremos false deste método.

422
00:20:41,143 --> 00:20:44,600
‫E isso significa que o usuário não alterou

423
00:20:44,600 --> 00:20:45,720
‫sua senha

424
00:20:45,720 --> 00:20:48,320
‫depois que o token foi emitido.

425
00:20:48,320 --> 00:20:50,410
‫OK?

426
00:20:50,410 --> 00:20:51,860
‫Então vamos colocar isso aqui, return false, basicamente por padrão.

427
00:20:51,860 --> 00:20:56,860
‫OK.

428
00:20:58,470 --> 00:20:59,303
‫Mas então,

429
00:20:59,303 --> 00:21:02,987
‫também temos if this, e lembre-se que em um método de instância,

430
00:21:02,987 --> 00:21:05,827
‫a palavra-chave this sempre aponta para o documento atual.

431
00:21:05,827 --> 00:21:09,477
‫E portanto, aqui temos acesso às propriedades.

432
00:21:09,477 --> 00:21:13,210
‫Agora, na verdade, precisamos criar um campo agora em nosso esquema

433
00:21:13,210 --> 00:21:16,280
‫para a data em que a senha foi alterada.

434
00:21:16,280 --> 00:21:18,750
‫Então, ainda não temos isso.

435
00:21:18,750 --> 00:21:20,050
‫Então, vamos adicioná-lo rapidamente aqui.

436
00:21:21,200 --> 00:21:23,713
‫Portanto, passwordChangedAt e o tipo dela

437
00:21:25,980 --> 00:21:27,813
‫será uma data.

438
00:21:31,320 --> 00:21:34,520
‫Agora, essa propriedade passwordChangedAt aqui sempre

439
00:21:34,520 --> 00:21:37,890
‫será alterada, é claro, quando alguém

440
00:21:37,890 --> 00:21:40,160
‫alterar a senha.

441
00:21:40,160 --> 00:21:42,910
‫Então, no momento, não temos essa lógica em nenhum lugar, e

442
00:21:42,910 --> 00:21:45,270
‫em nenhum lugar estamos realmente definindo essa propriedade.

443
00:21:45,270 --> 00:21:48,743
‫E assim, a maioria dos documentos, a

444
00:21:49,630 --> 00:21:53,230
‫maioria dos usuários, eles simplesmente não terão essa propriedade

445
00:21:53,230 --> 00:21:56,720
‫em seus dados, então em seu objeto, certo?

446
00:21:56,720 --> 00:21:58,600
‫E então, é claro, precisamos testar isso.

447
00:21:58,600 --> 00:22:01,363
‫OK?

448
00:22:03,430 --> 00:22:04,610
‫Portanto, se a

449
00:22:04,610 --> 00:22:07,740
‫propriedade passwordChangedAt existir, só então queremos realmente fazer a comparação.

450
00:22:07,740 --> 00:22:11,510
‫OK?

451
00:22:11,510 --> 00:22:12,343
‫Mas se

452
00:22:12,343 --> 00:22:16,010
‫não, se passwordChanged não existir, então isso significa que o usuário

453
00:22:16,010 --> 00:22:17,640
‫nunca alterou a senha de

454
00:22:17,640 --> 00:22:20,020
‫fato e, portanto, podemos simplesmente retornar false.

455
00:22:20,020 --> 00:22:23,171
‫Então, novamente, esse é o nosso padrão, o que significa

456
00:22:23,171 --> 00:22:25,560
‫que o usuário não alterou a

457
00:22:25,560 --> 00:22:28,190
‫senha após esse carimbo de data / hora.

458
00:22:28,190 --> 00:22:30,540
‫OK.

459
00:22:30,540 --> 00:22:31,373
‫E

460
00:22:31,373 --> 00:22:35,760
‫agora, apenas para começar, vamos realmente registrar isso no console. passwordChangedAt e, claro, o JWTTimestamp também, só

461
00:22:35,760 --> 00:22:37,933
‫para

462
00:22:39,370 --> 00:22:42,010
‫vermos como poderíamos compará-los.

463
00:22:42,010 --> 00:22:44,950
‫Tudo bem.

464
00:22:44,950 --> 00:22:45,783
‫E agora precisamos

465
00:22:47,560 --> 00:22:49,690
‫criar um usuário que tenha essa propriedade, certo?

466
00:22:49,690 --> 00:22:52,720
‫E novamente, mais tarde na seção, quando

467
00:22:52,720 --> 00:22:54,260
‫implementaremos a lógica

468
00:22:54,260 --> 00:22:57,280
‫para alterar a senha, definiremos essa propriedade.

469
00:22:57,280 --> 00:22:59,760
‫OK?

470
00:22:59,760 --> 00:23:00,593
‫Mas agora

471
00:23:00,593 --> 00:23:04,140
‫iremos, basicamente, configurá-lo artificialmente aqui quando criarmos um novo usuário.

472
00:23:04,140 --> 00:23:06,260
‫OK?

473
00:23:06,260 --> 00:23:07,093
‫Então, vamos colocar isso aqui.

474
00:23:08,690 --> 00:23:10,130
‫E aqui, qualquer data, na verdade, servirá.

475
00:23:10,130 --> 00:23:12,810
‫Digamos 30 de abril de 2019 aqui.

476
00:23:12,810 --> 00:23:17,810
‫E então isso deve ser analisado no MongoDB muito bem.

477
00:23:18,430 --> 00:23:21,313
‫Vamos tentar, ver se funciona.

478
00:23:22,460 --> 00:23:24,293
‫E isso não funcionou.

479
00:23:25,210 --> 00:23:26,520
‫Portanto, não foi possível analisar realmente a data, digamos.

480
00:23:26,520 --> 00:23:29,913
‫E, na verdade, preciso começar com o ano e

481
00:23:30,980 --> 00:23:33,710
‫depois com o dia no final.

482
00:23:33,710 --> 00:23:36,400
‫Então, 2019 e depois 30 de abril.

483
00:23:36,400 --> 00:23:41,050
‫Tente de novo.

484
00:23:41,050 --> 00:23:42,103
‫E então você vê que agora está realmente funcionando.

485
00:23:43,190 --> 00:23:45,300
‫Portanto, temos essa data analisada aqui.

486
00:23:45,300 --> 00:23:48,210
‫OK?

487
00:23:48,210 --> 00:23:49,350
‫Agora, para realmente ver

488
00:23:49,350 --> 00:23:51,910
‫o resultado disso, é claro que precisamos chamar esse método.

489
00:23:51,910 --> 00:23:55,040
‫OK?

490
00:23:55,040 --> 00:23:56,560
‫Então é isso que faremos aqui na etapa quatro.

491
00:23:56,560 --> 00:23:59,033
‫OK?

492
00:24:00,010 --> 00:24:01,110
‫E então, lembre-se

493
00:24:01,110 --> 00:24:04,630
‫de que podemos chamar esse método de instância em um documento do usuário.

494
00:24:04,630 --> 00:24:06,200
‫Então, FreshUser. alteradoPasswordAfter e, em seguida, esse carimbo

495
00:24:06,200 --> 00:24:09,197
‫de data / hora.

496
00:24:14,837 --> 00:24:17,370
‫Então isso é decodificado. iat, então emitido em, basicamente.

497
00:24:17,370 --> 00:24:22,370
‫Tudo bem.

498
00:24:25,450 --> 00:24:26,350
‫Então, vamos simplesmente ver o resultado disso.

499
00:24:26,350 --> 00:24:29,130
‫E então, é claro, isso deve agora,

500
00:24:29,130 --> 00:24:32,953
‫não aqui, então deve registrar no console esses dois valores.

501
00:24:33,870 --> 00:24:37,123
‫OK.

502
00:24:39,320 --> 00:24:40,153
‫Agora, é

503
00:24:40,153 --> 00:24:43,170
‫claro que preciso fazer login exatamente com esse usuário, então com o

504
00:24:43,170 --> 00:24:44,223
‫teste, então vamos lá.

505
00:24:47,780 --> 00:24:48,853
‫Conecte-se.

506
00:24:50,250 --> 00:24:51,173
‫Copie este token aqui novamente.

507
00:24:53,090 --> 00:24:56,200
‫E, novamente, vamos basicamente automatizar

508
00:24:56,200 --> 00:24:59,580
‫isso no próximo vídeo, na verdade.

509
00:24:59,580 --> 00:25:01,233
‫OK.

510
00:25:02,740 --> 00:25:03,700
‫Cole aqui.

511
00:25:03,700 --> 00:25:04,673
‫E agora, temos esse bug aqui.

512
00:25:05,670 --> 00:25:08,312
‫Então, eu apenas digitei errado o nome da função aqui.

513
00:25:08,312 --> 00:25:13,312
‫Bem, vamos apenas copiar.

514
00:25:13,670 --> 00:25:14,920
‫Tente de novo.

515
00:25:16,410 --> 00:25:17,403
‫Oh cara.

516
00:25:18,780 --> 00:25:20,150
‫O que há de errado agora?

517
00:25:20,150 --> 00:25:21,823
‫E vejo que simplesmente esqueci este registro aqui.

518
00:25:25,420 --> 00:25:27,633
‫Então, outro erro estúpido.

519
00:25:28,752 --> 00:25:30,090
‫Provavelmente viu aquele chegando.

520
00:25:30,090 --> 00:25:32,320
‫Mas agora vamos lá.

521
00:25:32,320 --> 00:25:33,550
‫Então, tudo funcionou

522
00:25:33,550 --> 00:25:35,120
‫bem, e tudo o que

523
00:25:35,120 --> 00:25:37,450
‫realmente queríamos ver agora são esses dois resultados.

524
00:25:37,450 --> 00:25:39,560
‫Basicamente, temos este aqui neste formato de data

525
00:25:39,560 --> 00:25:43,110
‫e, em seguida, o outro neste milissegundo ou segundo carimbo de data /

526
00:25:43,110 --> 00:25:43,943
‫hora aqui.

527
00:25:43,943 --> 00:25:47,600
‫E então, agora precisamos converter este passwordChangedAt também

528
00:25:47,600 --> 00:25:51,670
‫em um carimbo de data / hora como esse.

529
00:25:51,670 --> 00:25:54,240
‫Tudo bem?

530
00:25:54,240 --> 00:25:55,073
‫E então, para isso, vamos criar uma nova variável.

531
00:25:55,073 --> 00:25:57,853
‫Tão alterado Timestamp.

532
00:25:59,560 --> 00:26:01,330
‫E podemos usar isso. passwordChangedAt. consiga tempo.

533
00:26:03,800 --> 00:26:06,100
‫OK?

534
00:26:12,730 --> 00:26:13,563
‫E então,

535
00:26:13,563 --> 00:26:16,913
‫essa é uma das muitas funções de data que o JavaScript nos oferece.

536
00:26:16,913 --> 00:26:18,563
‫Tudo bem.

537
00:26:19,450 --> 00:26:20,960
‫E agora, vamos comparar rapidamente

538
00:26:20,960 --> 00:26:23,760
‫esses dois porque não estamos totalmente prontos ainda, na verdade.

539
00:26:23,760 --> 00:26:26,253
‫Então mandando só pra ver os resultados aqui.

540
00:26:28,770 --> 00:26:31,930
‫E então o que vemos aqui basicamente é que

541
00:26:31,930 --> 00:26:33,610
‫este aqui está

542
00:26:33,610 --> 00:26:36,580
‫agora, basicamente, em segundos, e este em milissegundos.

543
00:26:36,580 --> 00:26:38,210
‫Portanto, é 1000 vezes mais.

544
00:26:38,210 --> 00:26:40,540
‫E assim, sabemos que precisamos dividir isso por

545
00:26:40,540 --> 00:26:43,340
‫1000 e, em seguida, analisar tudo isso como um número inteiro.

546
00:26:45,630 --> 00:26:48,583
‫E para isso, usamos parseInt.

547
00:26:50,550 --> 00:26:52,820
‫Portanto, outra função JavaScript está disponível para números.

548
00:26:52,820 --> 00:26:57,180
‫E então também precisamos especificar a base.

549
00:26:57,180 --> 00:27:00,320
‫Portanto, este é um número de base 10.

550
00:27:00,320 --> 00:27:02,920
‫Tudo bem?

551
00:27:02,920 --> 00:27:03,970
‫E agora, vamos, na verdade, novamente, ver o resultado.

552
00:27:03,970 --> 00:27:07,373
‫E agora, isso parece muito mais amigável.

553
00:27:10,120 --> 00:27:13,360
‫OK.

554
00:27:13,360 --> 00:27:14,193
‫E então, agora vamos retornar nosso resultado.

555
00:27:14,193 --> 00:27:17,040
‫E, novamente, lembre-se de que falso significa não alterado.

556
00:27:17,040 --> 00:27:22,040
‫OK?

557
00:27:24,500 --> 00:27:25,520
‫E não alterado

558
00:27:25,520 --> 00:27:30,207
‫significa basicamente que o dia ou a hora em que o token foi emitido é menor que

559
00:27:32,300 --> 00:27:34,240
‫o carimbo de data / hora alterado.

560
00:27:34,240 --> 00:27:37,893
‫OK?

561
00:27:40,280 --> 00:27:41,113
‫Portanto, apenas como exemplo

562
00:27:44,330 --> 00:27:45,830
‫aqui, digamos que o token foi emitido no momento 100.

563
00:27:45,830 --> 00:27:49,327
‫Mas então, mudamos a senha, digamos, no tempo 200.

564
00:27:50,460 --> 00:27:53,843
‫OK?

565
00:27:55,240 --> 00:27:56,073
‫E assim,

566
00:27:56,073 --> 00:27:57,609
‫mudamos a senha depois que o

567
00:27:57,609 --> 00:27:59,840
‫token foi emitido e, portanto, isso agora é verdade.

568
00:27:59,840 --> 00:28:01,940
‫Tudo bem?

569
00:28:01,940 --> 00:28:03,379
‫E é exatamente isso que queremos retornar

570
00:28:03,379 --> 00:28:04,810
‫aqui, porque falso significa que

571
00:28:04,810 --> 00:28:06,910
‫não mudou e, portanto, verdadeiro, é claro, significa alterado.

572
00:28:06,910 --> 00:28:09,200
‫E então, é exatamente isso que temos aqui.

573
00:28:09,200 --> 00:28:11,980
‫Mas agora, digamos que a senha foi

574
00:28:11,980 --> 00:28:13,410
‫alterada pela última

575
00:28:13,410 --> 00:28:15,810
‫vez em 200, mas só depois

576
00:28:15,810 --> 00:28:18,640
‫disso, emitimos o token, digamos, no momento 300.

577
00:28:18,640 --> 00:28:21,260
‫E então, 300, menos de 200?

578
00:28:21,260 --> 00:28:23,660
‫Não, isso é falso.

579
00:28:23,660 --> 00:28:25,160
‫E então, retornamos falso, o que novamente significa não alterado.

580
00:28:25,160 --> 00:28:29,200
‫E é por isso que usamos este sinal de menos aqui.

581
00:28:29,200 --> 00:28:32,720
‫OK?

582
00:28:32,720 --> 00:28:33,553
‫Vamos voltar ao nosso controlador e realmente usá-lo.

583
00:28:36,800 --> 00:28:41,800
‫Portanto, se a senha foi realmente alterada,

584
00:28:45,480 --> 00:28:49,910
‫bem, neste caso, queremos um erro.

585
00:28:49,910 --> 00:28:53,030
‫Então, volte em seguida, novamente, um novo AppError.

586
00:28:53,030 --> 00:28:57,623
‫Recentemente...

587
00:29:02,970 --> 00:29:04,220
‫Por favor faça login novamente.

588
00:29:11,790 --> 00:29:13,620
‫OK.

589
00:29:13,620 --> 00:29:15,030
‫E mais uma vez, código 401.

590
00:29:15,030 --> 00:29:18,363
‫Tudo bem.

591
00:29:19,770 --> 00:29:20,820
‫Portanto, novamente, isso

592
00:29:20,820 --> 00:29:23,220
‫retornará verdadeiro se o usuário realmente alterar sua senha.

593
00:29:23,220 --> 00:29:25,790
‫E então, se tudo isso aqui for

594
00:29:25,790 --> 00:29:28,540
‫verdade, bem, então exatamente nesse caso é quando

595
00:29:28,540 --> 00:29:30,600
‫queremos que esse erro aconteça.

596
00:29:30,600 --> 00:29:33,220
‫Tudo bem?

597
00:29:33,220 --> 00:29:34,820
‫Então essa foi a última etapa.

598
00:29:34,820 --> 00:29:37,510
‫OK.

599
00:29:37,510 --> 00:29:38,952
‫Então, basicamente, se o código pode chegar

600
00:29:38,952 --> 00:29:41,030
‫ao final deste código aqui, só então, o próximo será executado.

601
00:29:41,030 --> 00:29:45,410
‫E então, com next, vamos para o próximo manipulador

602
00:29:45,410 --> 00:29:49,100
‫de rota, o que efetivamente significa conceder acesso

603
00:29:49,100 --> 00:29:51,470
‫a essa rota protegida.

604
00:29:51,470 --> 00:29:52,783
‫Vamos realmente colocar isso aqui.

605
00:29:53,750 --> 00:29:55,740
‫Conceda acesso à rota protegida.

606
00:29:55,740 --> 00:30:00,740
‫OK?

607
00:30:02,340 --> 00:30:03,597
‫Porque isso é realmente tudo o que o próximo faz.

608
00:30:03,597 --> 00:30:05,310
‫Em seguida, nos leva ao próximo

609
00:30:05,310 --> 00:30:08,070
‫middleware, que normalmente é, então, o próprio manipulador de rotas, ou

610
00:30:08,070 --> 00:30:10,880
‫seja, aquele que envia de volta os dados que estavam protegidos.

611
00:30:10,880 --> 00:30:14,550
‫OK.

612
00:30:14,550 --> 00:30:15,383
‫A última coisa

613
00:30:15,383 --> 00:30:18,540
‫que queremos fazer aqui é colocar todos os dados do usuário na solicitação.

614
00:30:18,540 --> 00:30:22,930
‫Portanto, podemos simplesmente dizer req, então solicite,. o usuário será igual ao

615
00:30:22,930 --> 00:30:27,100
‫freshUser.

616
00:30:27,100 --> 00:30:30,510
‫OK.

617
00:30:30,510 --> 00:30:31,343
‫E de novo,

618
00:30:31,343 --> 00:30:32,430
‫é claro, o código

619
00:30:32,430 --> 00:30:34,930
‫só chega a esse ponto aqui caso tudo esteja correto.

620
00:30:34,930 --> 00:30:37,470
‫OK?

621
00:30:37,470 --> 00:30:38,303
‫E então, isso

622
00:30:38,303 --> 00:30:40,710
‫aqui pode ser útil em algum momento no futuro.

623
00:30:40,710 --> 00:30:42,110
‫Excelente.

624
00:30:43,150 --> 00:30:43,983
‫Vamos testar isso mais uma vez.

625
00:30:43,983 --> 00:30:46,450
‫E, basicamente, essa mudança está no passado agora.

626
00:30:46,450 --> 00:30:51,450
‫E então, esse token que temos aqui, ou na verdade, eu

627
00:30:51,820 --> 00:30:53,840
‫poderia ter reutilizado

628
00:30:53,840 --> 00:30:56,890
‫apenas este em vez de registrá-lo novamente.

629
00:30:56,890 --> 00:30:58,520
‫Mas de qualquer maneira, este

630
00:30:58,520 --> 00:31:00,500
‫token foi emitido após a alteração da senha.

631
00:31:00,500 --> 00:31:02,344
‫E então, este token agora deve funcionar.

632
00:31:02,344 --> 00:31:04,920
‫Então, vamos realmente fazer login

633
00:31:04,920 --> 00:31:07,500
‫novamente e tentar com este token.

634
00:31:10,900 --> 00:31:13,203
‫E, de fato, temos acesso.

635
00:31:18,020 --> 00:31:20,030
‫Agora, indo para o Compass para alterar essa data.

636
00:31:20,030 --> 00:31:22,853
‫OK.

637
00:31:24,511 --> 00:31:26,010
‫Vamos colocar um mês depois.

638
00:31:26,010 --> 00:31:27,657
‫E então, isso será no

639
00:31:27,657 --> 00:31:30,780
‫futuro, pelo menos, no meu futuro quando eu estiver gravando este vídeo.

640
00:31:30,780 --> 00:31:34,150
‫Claro, você fará isso mais tarde.

641
00:31:34,150 --> 00:31:36,640
‫E então, para testar isso, por favor, coloque isso em seu futuro.

642
00:31:36,640 --> 00:31:40,373
‫Então, no futuro da data em que você está

643
00:31:41,420 --> 00:31:43,060
‫assistindo este vídeo.

644
00:31:43,060 --> 00:31:44,710
‫Portanto, se eu

645
00:31:45,960 --> 00:31:50,960
‫voltar ao Postman e efetuar login novamente, ok, se eu efetuar login

646
00:31:53,860 --> 00:31:56,430
‫novamente agora e tentar acessar essa

647
00:31:56,430 --> 00:31:58,710
‫rota, bem, este token será

648
00:31:58,710 --> 00:32:01,420
‫emitido, basicamente, após a alteração da senha.

649
00:32:01,420 --> 00:32:03,553
‫Ou, na verdade, antes que a senha seja alterada.

650
00:32:08,680 --> 00:32:10,590
‫Então, desculpe por essa confusão.

651
00:32:10,590 --> 00:32:12,610
‫Portanto, a senha foi alterada em 30 de

652
00:32:12,610 --> 00:32:15,800
‫maio, mas este token foi emitido em 2 de maio, e assim, antes.

653
00:32:15,800 --> 00:32:19,650
‫Então, basicamente, agora é como se o usuário tivesse alterado sua senha

654
00:32:19,650 --> 00:32:21,950
‫depois que o token foi emitido.

655
00:32:21,950 --> 00:32:25,880
‫E então, essa é exatamente a situação em que não queremos dar

656
00:32:25,880 --> 00:32:27,341
‫acesso à rota protegida.

657
00:32:27,341 --> 00:32:31,070
‫E então, isso agora deve refletir isso.

658
00:32:31,070 --> 00:32:35,170
‫E, de fato, o usuário alterou a

659
00:32:35,170 --> 00:32:38,740
‫senha recentemente, faça o login novamente.

660
00:32:38,740 --> 00:32:40,280
‫Excelente.

661
00:32:40,280 --> 00:32:41,240
‫Então agora funciona.

662
00:32:41,240 --> 00:32:42,953
‫Portanto, nosso middleware de proteção agora está completamente implementado.

663
00:32:43,870 --> 00:32:48,000
‫Vamos nos livrar deste console. faça login aqui.

664
00:32:48,000 --> 00:32:51,620
‫Não preciso mais disso.

665
00:32:51,620 --> 00:32:53,820
‫E tudo bem.

666
00:32:53,820 --> 00:32:55,800
‫Então, vamos recapitular rapidamente, e este

667
00:32:55,800 --> 00:32:57,230
‫vídeo está demorando muito,

668
00:32:57,230 --> 00:32:59,520
‫um pouco mais do que eu esperava.

669
00:32:59,520 --> 00:33:01,330
‫Mas é muito

670
00:33:01,330 --> 00:33:03,820
‫importante entender e explicar como tudo

671
00:33:03,820 --> 00:33:06,700
‫isso funciona e por que é importante.

672
00:33:06,700 --> 00:33:07,810
‫E então, eu prefiro isso do que fazer este vídeo muito mais curto.

673
00:33:07,810 --> 00:33:12,710
‫Claro, eu poderia simplesmente escrever o código, mas você não entenderia realmente o

674
00:33:12,710 --> 00:33:14,127
‫que está acontecendo.

675
00:33:14,127 --> 00:33:17,330
‫Então essa parte a gente já entendeu.

676
00:33:17,330 --> 00:33:19,410
‫Então, essa parte, também acredito,

677
00:33:19,410 --> 00:33:21,680
‫então é aqui que a verificação acontece,

678
00:33:21,680 --> 00:33:24,060
‫basicamente ver se a carga útil do

679
00:33:24,060 --> 00:33:26,570
‫token não foi manipulada por algum terceiro malicioso.

680
00:33:26,570 --> 00:33:30,900
‫OK?

681
00:33:30,900 --> 00:33:31,733
‫E como chegamos

682
00:33:31,733 --> 00:33:33,730
‫a esse código aqui, isso significa que ninguém

683
00:33:33,730 --> 00:33:36,790
‫alterou o token da web JSON e, portanto, podemos obter um novo usuário.

684
00:33:36,790 --> 00:33:39,350
‫Então, basicamente, podemos obter o usuário

685
00:33:39,350 --> 00:33:41,690
‫atual, vamos chamá-lo de currentUser.

686
00:33:41,690 --> 00:33:43,650
‫Por que não?

687
00:33:43,650 --> 00:33:44,483
‫Então, aqui, aqui e também aqui.

688
00:33:45,450 --> 00:33:47,993
‫OK?

689
00:33:49,670 --> 00:33:50,503
‫Portanto, podemos obter

690
00:33:50,503 --> 00:33:53,020
‫o currentUser desse ID que acabou de ser decodificado da carga útil.

691
00:33:53,020 --> 00:33:55,023
‫Agora, se o currentUser não existe,

692
00:33:56,100 --> 00:33:58,260
‫então é para isso que estamos testando

693
00:33:58,260 --> 00:34:00,660
‫aqui, bem, então, nesse caso, não queremos dar

694
00:34:00,660 --> 00:34:01,990
‫acesso à rota

695
00:34:01,990 --> 00:34:04,290
‫e, em vez disso, criar este novo erro.

696
00:34:04,290 --> 00:34:06,343
‫Mas se o usuário existe, então

697
00:34:07,400 --> 00:34:08,870
‫vamos para o

698
00:34:08,870 --> 00:34:12,030
‫ponto número quatro, onde verificamos se uma mudança de

699
00:34:12,030 --> 00:34:15,060
‫senha aconteceu depois que o token foi emitido, certo?

700
00:34:15,060 --> 00:34:18,060
‫E se assim foi, então, novamente, criamos um novo erro.

701
00:34:18,060 --> 00:34:21,200
‫E se não funcionou, então vamos até

702
00:34:21,200 --> 00:34:22,720
‫o final da

703
00:34:22,720 --> 00:34:24,460
‫função de middleware, onde

704
00:34:24,460 --> 00:34:26,750
‫atribuímos o currentUser para solicitar. usuário para que possamos usá-lo em

705
00:34:26,750 --> 00:34:30,640
‫uma próxima função de middleware.

706
00:34:30,640 --> 00:34:33,860
‫OK?

707
00:34:33,860 --> 00:34:34,693
‫Porque lembre-se,

708
00:34:34,693 --> 00:34:37,030
‫esse objeto de solicitação, é aquele que viaja,

709
00:34:37,030 --> 00:34:38,950
‫basicamente, do middleware para o middleware.

710
00:34:38,950 --> 00:34:40,660
‫E então, se quisermos passar dados

711
00:34:40,660 --> 00:34:42,330
‫de um middleware para o

712
00:34:42,330 --> 00:34:44,600
‫próximo, podemos simplesmente colocar algumas coisas no objeto

713
00:34:44,600 --> 00:34:47,860
‫de solicitação, e então esses dados estarão disponíveis em um ponto posterior.

714
00:34:47,860 --> 00:34:51,220
‫Tudo bem.

715
00:34:51,220 --> 00:34:52,053
‫Então é isso.

716
00:34:52,053 --> 00:34:52,886
‫Este é

717
00:34:52,886 --> 00:34:54,560
‫um algoritmo de proteção de rota

718
00:34:54,560 --> 00:34:58,300
‫muito sofisticado e muito completo, basicamente, mas acho que é realmente importante fazê-lo

719
00:34:58,300 --> 00:34:59,740
‫o melhor que pudermos.

720
00:34:59,740 --> 00:35:02,820
‫De qualquer forma, fico feliz em ver que você

721
00:35:02,820 --> 00:35:04,990
‫chegou ao final desse grande vídeo,

722
00:35:04,990 --> 00:35:07,050
‫e vejo você no próximo.