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

2
00:00:04,614 --> 00:00:09,792
Nós já tínhamos desenvolvido um servidor API REST completo usando Express e

3
00:00:09,792 --> 00:00:12,026
MongoDB como parte deste curso.

4
00:00:12,026 --> 00:00:16,881
Para que o servidor possa se comunicar de forma significativa com nosso cliente,

5
00:00:16,881 --> 00:00:21,892
faremos alguns pequenos ajustes para que ele retorne o tipo certo de dados.

6
00:00:21,892 --> 00:00:26,063
Para que a implementação de nosso cliente possa trabalhar de forma mais eficiente

7
00:00:26,063 --> 00:00:29,370
com os dados retornados do lado do servidor.

8
00:00:29,370 --> 00:00:30,427
Então, para fazer isso,

9
00:00:30,427 --> 00:00:35,724
vamos trabalhar em alguns ajustes para o nosso lado do servidor neste exercício.

10
00:00:37,478 --> 00:00:43,220
Indo ao nosso servidor no editor, antes de começarmos a trabalhar no servidor,

11
00:00:43,220 --> 00:00:48,497
sugiro que você baixe todas as imagens que forneci

12
00:00:48,497 --> 00:00:53,260
como um arquivo zip nos recursos de exercício chamados images.zip.

13
00:00:53,260 --> 00:00:56,530
Descompacte o arquivo e, em seguida, obtenha todas as imagens de lá e, em

14
00:00:56,530 --> 00:01:03,440
seguida, copie essas imagens para a pasta de imagens públicas em nosso servidor.

15
00:01:03,440 --> 00:01:08,980
Então você vê que aqui eu copiei todas as imagens para a minha

16
00:01:08,980 --> 00:01:10,580
pasta de imagens públicas aqui.

17
00:01:10,580 --> 00:01:15,120
Porque o nosso servidor é aquele que vai servir todas essas imagens para a

18
00:01:15,120 --> 00:01:17,460
nossa aplicação cliente.

19
00:01:17,460 --> 00:01:22,820
Em seguida, vamos para os cors e ajustamos essa lista branca, aqui.

20
00:01:22,820 --> 00:01:27,919
Então, para o nosso aplicativo cliente Angular, se iniciarmos

21
00:01:27,919 --> 00:01:33,571
com o comando ng serve, ele será executado no localhost :4200.

22
00:01:33,571 --> 00:01:36,196
Portanto, quaisquer pedidos que venham da nossa

23
00:01:36,196 --> 00:01:40,750
aplicação Angular para o servidor levarão isso como sua origem lá.

24
00:01:40,750 --> 00:01:44,710
Então é por isso que vou adicionar isso à minha lista branca, para

25
00:01:44,710 --> 00:01:50,310
que quaisquer problemas de cors sejam resolvidos automaticamente.

26
00:01:50,310 --> 00:01:54,848
Então, indo para o arquivo cors.js,

27
00:01:54,848 --> 00:01:59,698
na minha lista branca, aqui, deixe-me adicionar

28
00:01:59,698 --> 00:02:08,371
no http://localhost:, 4200.

29
00:02:08,371 --> 00:02:12,503
E esta é a origem da qual todo o meu cliente Angular será

30
00:02:12,503 --> 00:02:16,690
originado o pedido que vier a este servidor.

31
00:02:16,690 --> 00:02:22,020
Assim, meus cors não causarão problemas para meu cliente Angular.

32
00:02:22,020 --> 00:02:27,760
Em seguida, precisamos atualizar algumas das rotas para lidar com

33
00:02:27,760 --> 00:02:32,760
os parâmetros de consulta, e também alguns pequenos outros ajustes.

34
00:02:32,760 --> 00:02:35,905
Deixe-me começar com os arquivos promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
Então isso é simples de se atualizar.

36
00:02:39,760 --> 00:02:44,790
Então, indo para o arquivo promoRouter.js, no arquivo PromOrouter, para

37
00:02:44,790 --> 00:02:47,960
a solicitação get que recebemos aqui,

38
00:02:47,960 --> 00:02:52,400
em vez de fazer promotions.Find com um JavaScript vazio,

39
00:02:52,400 --> 00:02:57,256
aqui eu forneceria o req.query como

40
00:02:57,256 --> 00:03:02,470
o parâmetro para que promotions.Find aqui. A

41
00:03:02,470 --> 00:03:07,650
mesma coisa com o LeaderRouter também, então deixe-me ir para o arquivo leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
E no LeaderRouter também,

43
00:03:09,786 --> 00:03:14,642
aqui onde você encontra Leaders.Find com o objeto JavaScript vazio.

44
00:03:14,642 --> 00:03:18,423
Em vez disso, substitua esse req.query, para

45
00:03:18,423 --> 00:03:21,852
que os parâmetros de consulta sejam passados.

46
00:03:21,852 --> 00:03:26,430
Então, este é o lugar onde vamos passar na coluna em destaque

47
00:03:26,430 --> 00:03:29,487
através como o parâmetro de consulta.

48
00:03:29,487 --> 00:03:34,678
Agora tendo ajustado esses dois, vamos agora trabalhar na rota do prato,

49
00:03:34,678 --> 00:03:41,090
então indo para o arquivo dishRouter.js, mesmo no DishRouter, a mesma atualização aqui.

50
00:03:41,090 --> 00:03:48,920
Então, indo para este dishes.Find no método get aqui, altere isso para req.query.

51
00:03:48,920 --> 00:03:52,987
Então, com isso, minha atualização DISHRouter foi concluída.

52
00:03:52,987 --> 00:03:57,664
Então, agora atualizamos o PromOrouter, o ReaderRouter e

53
00:03:57,664 --> 00:04:02,784
o DisishRouter, então vamos passar para atualizar esse FavoriteOuter.

54
00:04:02,784 --> 00:04:07,519
Agora você teria implementado o roteador favorito como parte de sua

55
00:04:07,519 --> 00:04:09,500
quarta atribuição.

56
00:04:09,500 --> 00:04:12,306
Agora, no FavoriterOuter, você verá que para

57
00:04:12,306 --> 00:04:16,618
o FavoriterOuter eu não estou mostrando o parter restante porque

58
00:04:16,618 --> 00:04:19,437
você deveria ter feito como parte de sua tarefa.

59
00:04:19,437 --> 00:04:22,925
Deixe-me primeiro chamar sua atenção para o método get para

60
00:04:22,925 --> 00:04:26,422
o favoriteRouter.route (“/:dishid').

61
00:04:26,422 --> 00:04:31,161
Agora, eu vou usar este método get para apenas

62
00:04:31,161 --> 00:04:35,653
verificar para garantir que o prato específico com

63
00:04:35,653 --> 00:04:40,292
um DishID já é um favorito para o usuário.

64
00:04:40,292 --> 00:04:44,413
Então, em vez de simplesmente dizer operação GET não suportada,

65
00:04:44,413 --> 00:04:48,879
eu vou apenas alavancar a presença desta operação get.

66
00:04:48,879 --> 00:04:52,574
E então diremos,

67
00:04:52,574 --> 00:04:56,684
favoritos. Findone.

68
00:04:56,684 --> 00:04:59,843
E eu vou dizer,

69
00:04:59,843 --> 00:05:04,952
usuário: req.user.id

70
00:05:04,952 --> 00:05:10,194
Então vamos encontrar os favoritos para esse usuário em particular.

71
00:05:10,194 --> 00:05:20,166
E então diremos, então, favoritos.

72
00:05:26,483 --> 00:05:32,913
E, catch ((err),

73
00:05:35,757 --> 00:05:40,160
próximo (err)).

74
00:05:40,160 --> 00:05:45,638
E então, da mesma forma aqui, adicionaremos o erro aqui.

75
00:05:48,689 --> 00:05:50,239
Próximo (err)), aqui.

76
00:05:50,239 --> 00:05:55,689
Então, dentro deste .então, quando obtivermos os favoritos,

77
00:05:55,689 --> 00:06:00,290
então vamos verificar, se (! favoritos).

78
00:06:00,290 --> 00:06:04,500
Então, se não houver favoritos para este usuário,

79
00:06:04,500 --> 00:06:08,770
então, obviamente, o prato que estamos verificando não existe.

80
00:06:08,770 --> 00:06:18,604
Então vamos retornar, Res.StatusCode, 200.

81
00:06:22,232 --> 00:06:29,488
SetHeader ('Content-Type

82
00:06:29,488 --> 00:06:34,436
'' application/json ').

83
00:06:34,436 --> 00:06:36,237
E então retornaremos,

84
00:06:42,997 --> 00:06:51,490
dizendo, “existe”: falso.

85
00:06:51,490 --> 00:06:56,891
Então o que estamos especificando aqui é que se o get é feito

86
00:06:56,891 --> 00:07:02,771
para este endpoint com um DishID, esta bandeira existe aqui

87
00:07:02,771 --> 00:07:07,826
será definida como true se este prato é parte dos meus favoritos.

88
00:07:07,826 --> 00:07:13,008
Se este prato não faz parte dos meus favoritos, vou definir a bandeira existe como false.

89
00:07:13,008 --> 00:07:16,687
Então aqui, você vê que uma vez que eu não tenho nenhum favorito, então

90
00:07:16,687 --> 00:07:20,008
existe deve ser automaticamente falso neste ponto.

91
00:07:20,008 --> 00:07:26,780
Então vamos dizer “existe”: falso, e então retornaremos os favoritos, aqui.

92
00:07:28,950 --> 00:07:31,237
Bem, obviamente, neste caso,

93
00:07:31,237 --> 00:07:35,225
os favoritos seriam nulos neste momento, caso contrário.

94
00:07:39,097 --> 00:07:42,779
Então, o que significa que os favoritos não é nulo, então vamos dizer se,

95
00:07:45,218 --> 00:07:52,688
(favorites.dish.indexOf),

96
00:07:52,688 --> 00:07:58,011
então vamos estar procurando por req.params.

97
00:08:00,046 --> 00:08:02,620
DisHid, então vamos procurar isso.

98
00:08:02,620 --> 00:08:09,632
Favorites.dishes.Array, para ver se o prato existe lá.

99
00:08:09,632 --> 00:08:15,410
E se não existir, obviamente isso retornará um índice negativo aqui.

100
00:08:15,410 --> 00:08:20,200
Então, nesse caso também, retornarei exatamente o mesmo que aqui.

101
00:08:20,200 --> 00:08:22,291
Então, se ele retorna um índice negativo,

102
00:08:22,291 --> 00:08:26,990
então isso significa que, mesmo que este usuário em particular tenha um favorito central.

103
00:08:26,990 --> 00:08:31,464
Este prato específico não existe na lista o

104
00:08:31,464 --> 00:08:36,987
seu favorito, então é por isso que ele vai voltar existir falso aqui.

105
00:08:36,987 --> 00:08:45,119
Agora, caso contrário, isso significa que o prato existe na lista de favoritos.

106
00:08:45,119 --> 00:08:51,352
Então, neste caso, eu retornarei o código de status 200 existe é verdadeiro.

107
00:08:51,352 --> 00:08:57,144
Assim, quando o usuário executa uma operação get

108
00:08:57,144 --> 00:09:02,408
neste ponto final com o /Favorite/dishid.

109
00:09:02,408 --> 00:09:07,265
Onde o DishID é fornecido como o parâmetro aqui.

110
00:09:07,265 --> 00:09:09,821
Como o parâmetro records aqui,

111
00:09:09,821 --> 00:09:15,226
então vamos verificar se esse prato existe nos favoritos.

112
00:09:15,226 --> 00:09:19,983
Se nenhum dos favoritos existir para este usuário, em seguida, vamos retornar um existe false.

113
00:09:19,983 --> 00:09:22,138
Da mesma forma, se os favoritos existem,

114
00:09:22,138 --> 00:09:27,000
mas esse prato particular não existe nos favoritos, então ele retornará um falso.

115
00:09:27,000 --> 00:09:28,705
Caso contrário, ele retornará um verdadeiro.

116
00:09:28,705 --> 00:09:33,890
Então esta bandeira existe pode ser usado pelo meu cliente

117
00:09:33,890 --> 00:09:41,997
para verificar se este prato é parte da lista de pratos favoritos para este usuário ou não.

118
00:09:41,997 --> 00:09:48,624
Finalmente vamos atualizar o arquivo users.js.

119
00:09:48,624 --> 00:09:53,284
Agora, no arquivo users.js, precisamos adicionar em

120
00:09:53,284 --> 00:09:58,204
outro campo roteador.options aqui porque

121
00:09:58,204 --> 00:10:03,769
às vezes uma solicitação Post como você viu com o login,

122
00:10:03,769 --> 00:10:10,760
vamos enviar as opções primeiro para verificar, especialmente com carros,

123
00:10:10,760 --> 00:10:16,140
se a solicitação de postagem será permitida.

124
00:10:16,140 --> 00:10:23,156
Então é por isso que eles vão verificar carros, carros com opções aqui e depois.

125
00:10:26,156 --> 00:10:27,915
Nós simplesmente retornaremos

126
00:10:34,203 --> 00:10:39,938
uma mensagem de status de 200 em resposta a isso.

127
00:10:39,938 --> 00:10:44,624
Então, para qualquer endpoint sob usuários, se recebemos

128
00:10:44,624 --> 00:10:50,183
as opções simplesmente retornará um status 200 aqui.

129
00:10:50,183 --> 00:10:57,417
Agora a função Login que tínhamos implementado anteriormente.

130
00:10:57,417 --> 00:11:02,782
Nós simplesmente fizemos passport.authenticate ('local') aqui e

131
00:11:02,782 --> 00:11:06,600
, em seguida, verificamos para os valores restantes aqui.

132
00:11:06,600 --> 00:11:11,006
Agora este passport.authenticate ('local'), se o usuário não for

133
00:11:11,006 --> 00:11:15,221
autenticado, ele simplesmente retorna um não autorizado na mensagem de resposta.

134
00:11:15,221 --> 00:11:18,212
Agora isso pode não ser muito significativo para

135
00:11:18,212 --> 00:11:21,868
o lado do cliente exibir essas informações.

136
00:11:21,868 --> 00:11:27,245
É por isso que vamos melhorar este método de pós-login do roteador de

137
00:11:27,245 --> 00:11:35,158
modo que a autenticação retorne informações mais significativas nesta parte.

138
00:11:35,158 --> 00:11:39,831
Então, para fazer isso, não vamos fazer a

139
00:11:39,831 --> 00:11:43,120
autenticação do passaporte aqui dentro.

140
00:11:43,120 --> 00:11:47,180
Em vez disso, vamos tomar, então deixe-me remover isso de lá,

141
00:11:47,180 --> 00:11:52,410
e então você vai ver como eu vou atualizar a postagem do roteador aqui.

142
00:11:52,410 --> 00:11:56,520
Então vamos ver CarsWithOptions.

143
00:11:56,520 --> 00:12:03,806
E então vamos incluir o req, res e o próximo aqui.

144
00:12:03,806 --> 00:12:08,216
E dentro da requisição, res, e a

145
00:12:08,216 --> 00:12:14,227
seguir aqui, passaporte. Authenticate,

146
00:12:17,271 --> 00:12:22,035
chamaremos isso com “local”.

147
00:12:22,035 --> 00:12:27,041
Agora, quando chamamos isso com local, se

148
00:12:27,041 --> 00:12:34,607
ocorrer um erro de autenticação, o passport.authenticate pode ser feito para retornar o valor do erro,

149
00:12:34,607 --> 00:12:39,519
e também ele retornará o usuário se não houver nenhum erro.

150
00:12:39,519 --> 00:12:42,283
E ele poderia parâmetro chamado info,

151
00:12:42,283 --> 00:12:47,643
que irá levar informações adicionais que podem ser passadas de volta para o usuário.

152
00:12:47,643 --> 00:12:51,714
Esse erro será retornado quando houver um erro genuíno que ocorre

153
00:12:51,714 --> 00:12:53,590
no possível para autenticar.

154
00:12:53,590 --> 00:12:58,995
Mas se as informações do usuário são enviadas para passport.authenticate, mas

155
00:12:58,995 --> 00:13:03,945
o usuário não existe, então isso não é contado como um erro.

156
00:13:03,945 --> 00:13:07,828
Em vez disso, ele será contado como o usuário não existe.

157
00:13:07,828 --> 00:13:12,825
E essa informação é passada de volta no objeto info que entra.

158
00:13:12,825 --> 00:13:16,793
Portanto, o erro será retornado quando houver um erro genuíno que ocorre durante

159
00:13:16,793 --> 00:13:18,405
o processo de autenticação.

160
00:13:18,405 --> 00:13:23,995
Mas as informações, eles conterão informações se o usuário não existir e, portanto,

161
00:13:23,995 --> 00:13:30,102
o passport.authenticate está passando de volta uma mensagem dizendo que o usuário não

162
00:13:30,102 --> 00:13:35,780
existe ou que o nome de usuário está incorreto ou a senha está incorreta.

163
00:13:35,780 --> 00:13:40,415
E assim por diante, para que a informação seja passada, na mensagem info.

164
00:13:40,415 --> 00:13:44,569
Agora, vamos ver como isso é útil para nós quando olharmos para o lado do cliente um

165
00:13:44,569 --> 00:13:45,990
pouco mais tarde.

166
00:13:45,990 --> 00:13:48,070
Então, nesta situação,

167
00:13:49,530 --> 00:13:55,110
vamos lidar com isso da seguinte forma.

168
00:13:55,110 --> 00:14:00,510
E não só isso, quando chamamos este passaporte autenticar,

169
00:14:00,510 --> 00:14:04,976
também precisamos passar em um (req, res,

170
00:14:04,976 --> 00:14:08,550
próximo) como essa tira de três parâmetros.

171
00:14:08,550 --> 00:14:10,320
Então esta é a estrutura.

172
00:14:10,320 --> 00:14:13,558
Quando você precisar chamar o passaporte autenticar,

173
00:14:13,558 --> 00:14:18,798
espere que ele lhe passe informações como esta como um método de retorno de chamada aqui.

174
00:14:18,798 --> 00:14:24,072
Então você também precisa fornecer este req, res próximo bem ali também.

175
00:14:24,072 --> 00:14:25,720
Agora, se isso ocorrer.

176
00:14:25,720 --> 00:14:30,206
Então vamos dizer se (err).

177
00:14:30,206 --> 00:14:34,163
Então, se ocorrer um erro,

178
00:14:34,163 --> 00:14:39,781
diremos retorno próximo (err) e deixar que o

179
00:14:39,781 --> 00:14:45,028
manipulador de erros do nosso roteador expresso cuide disso.

180
00:14:45,028 --> 00:14:48,365
Agora, vamos considerar outras situações.

181
00:14:48,365 --> 00:14:53,484
Se (! usuário), então se chegamos a este ponto, então isso significa que

182
00:14:53,484 --> 00:14:59,232
não foi um erro que ocorreu, mas em vez disso, talvez o usuário não pôde ser encontrado.

183
00:14:59,232 --> 00:15:04,860
Se o usuário não for encontrado, então o usuário aqui será definido como null neste caso.

184
00:15:04,860 --> 00:15:10,088
Então, nessa situação, se o usuário não existir,

185
00:15:10,088 --> 00:15:17,068
então precisamos ser capazes de passar informações de volta para o lado do servidor.

186
00:15:17,068 --> 00:15:22,895
Então o que vamos fazer é passar essa informação neste formato,

187
00:15:22,895 --> 00:15:26,576
então eu vou cortar isso daqui, e

188
00:15:26,576 --> 00:15:30,491
então colá-lo aqui e então vamos editar isso.

189
00:15:30,491 --> 00:15:36,748
Se o usuário é nulo, então vamos enviar de volta um

190
00:15:36,748 --> 00:15:41,509
StatusCode de 401 o que significa não autorizado, e

191
00:15:41,509 --> 00:15:47,640
então vamos enviar de volta sucesso informações, false.

192
00:15:47,640 --> 00:15:54,340
E então não passaremos o token, passaremos a mensagem de status.

193
00:15:54,340 --> 00:16:02,501
Então, aqui vamos dizer login, Sem sucesso.

194
00:16:02,501 --> 00:16:07,870
E então a terceira informação passará essa informação,

195
00:16:07,870 --> 00:16:13,238
esse objeto que recebemos aqui como a terceira parte da

196
00:16:13,238 --> 00:16:19,231
mensagem de resposta que enviamos de volta do nosso servidor aqui.

197
00:16:19,231 --> 00:16:22,496
Assim, o sinalizador de sucesso será redefinido para false.

198
00:16:22,496 --> 00:16:27,145
O status será definido Login Inbem-sucedido e as informações de erro,

199
00:16:27,145 --> 00:16:30,235
que são transmitidas nas informações serão repassadas.

200
00:16:30,235 --> 00:16:34,788
Agora observe que essa situação ocorrerá se o nome de usuário e

201
00:16:34,788 --> 00:16:36,789
a senha estiverem incorretos.

202
00:16:36,789 --> 00:16:42,516
E, portanto, isso não é um erro, no sentido do erro, mas o fato de que a autenticação

203
00:16:42,516 --> 00:16:47,505
não conseguiu encontrar o usuário ou a senha do usuário está incorreto.

204
00:16:47,505 --> 00:16:51,545
Então essa informação será codificada no fluxo de entrada que entra, e

205
00:16:51,545 --> 00:16:58,227
assim eu vou passar de volta como um erro para o lado do meu cliente.

206
00:16:58,227 --> 00:17:02,633
Caso contrário, parte é

207
00:17:02,633 --> 00:17:08,810
tratada como Req.Login.

208
00:17:08,810 --> 00:17:10,700
Então, se isso for bem-sucedido,

209
00:17:10,700 --> 00:17:16,200
o passport.authenticate adicionará esse método chamado req.Login ao usuário.

210
00:17:16,200 --> 00:17:21,400
Então, neste ponto, vamos apenas passar no objeto de usuário que obtivemos.

211
00:17:21,400 --> 00:17:26,398
Então aqui, se chegamos a este ponto,

212
00:17:26,398 --> 00:17:32,572
então isso significa que o objeto do usuário não é nulo e

213
00:17:32,572 --> 00:17:37,717
também nenhum erro ocorreu, então isso significa que

214
00:17:37,717 --> 00:17:43,304
o usuário pode ser logado e assim vamos dizer err.

215
00:17:43,304 --> 00:17:44,995
Então, ele tentará fazer login no usuário.

216
00:17:44,995 --> 00:17:47,231
Então vamos dizer se errar.

217
00:17:51,210 --> 00:17:58,260
E então passaremos o mesmo tipo de informação de erro que fizemos aqui.

218
00:17:59,450 --> 00:18:02,317
Então, neste caso, se o erro. Em

219
00:18:06,077 --> 00:18:11,757
caso de erro, passaremos de volta o código de status 401 e

220
00:18:11,757 --> 00:18:18,970
diremos que o sucesso é falso e o status é Login sem êxito.

221
00:18:18,970 --> 00:18:24,359
E, em seguida, as informações de erro que

222
00:18:24,359 --> 00:18:29,539
passaremos isso como em vez de

223
00:18:29,539 --> 00:18:36,810
informações que passaremos não pôde fazer login usuário.

224
00:18:36,810 --> 00:18:42,580
Então essa é a mensagem que passará aqui, se o erro ocorrer.

225
00:18:42,580 --> 00:18:46,195
Caso contrário, estaríamos aqui embaixo.

226
00:18:46,195 --> 00:18:53,157
E assim, neste ponto, seríamos capazes de gerar o token.

227
00:18:53,157 --> 00:18:57,594
Então, se chegamos até este ponto isso significa que o usuário fez

228
00:18:57,594 --> 00:19:01,892
login com sucesso e assim podemos agora gerar o token.

229
00:19:01,892 --> 00:19:07,009
Então vamos gerar o token com base no ID do usuário e

230
00:19:07,009 --> 00:19:11,794
, em seguida, vamos passar de volta esse token de volta para o usuário.

231
00:19:11,794 --> 00:19:15,462
Então, aqui vamos dizer var token.

232
00:19:15,462 --> 00:19:22,789
E então podemos dizer Res.statusCode = 200 e, em seguida, res.json (sucesso) é verdadeiro, o

233
00:19:22,789 --> 00:19:26,999
que significa que o usuário logado com sucesso.

234
00:19:26,999 --> 00:19:31,842
E assim o status seria Login bem-sucedido e, em

235
00:19:31,842 --> 00:19:39,900
seguida, a terceira parte em vez do erro, passarei o token de volta para o usuário.

236
00:19:39,900 --> 00:19:45,590
Então, vamos dizer token, token,

237
00:19:45,590 --> 00:19:50,390
este token que acabamos de obter anteriormente, de modo que para token será passado

238
00:19:50,390 --> 00:19:54,600
como a propriedade token da mensagem de luz rip.

239
00:19:54,600 --> 00:19:57,910
Então, aqui, observe que este eixo está definido como verdadeiro.

240
00:19:57,910 --> 00:20:01,890
Então, o que significa que o usuário logou com sucesso.

241
00:20:01,890 --> 00:20:05,660
E assim o usuário pode avançar neste ponto.

242
00:20:05,660 --> 00:20:13,667
E isso tem que ser feito dentro do Req.Login aqui.

243
00:20:13,667 --> 00:20:20,640
Então, neste ponto, vamos fechar o Req.Login.

244
00:20:20,640 --> 00:20:27,570
Então note que isso está dentro deste Req.Login aqui.

245
00:20:27,570 --> 00:20:30,830
Então lá dentro vamos passar esses três de volta.

246
00:20:30,830 --> 00:20:33,800
Então deixe-me apenas recuar três linhas em.

247
00:20:35,830 --> 00:20:42,490
E assim é como nós lidaríamos com o login dos usuários.

248
00:20:42,490 --> 00:20:45,850
Então, novamente, revisando este código mais uma vez.

249
00:20:45,850 --> 00:20:47,740
Então vamos fazer postagem de roteador, mas

250
00:20:47,740 --> 00:20:52,490
em vez de fazer autenticação de passaporte ali mesmo, vamos dizer req, res,

251
00:20:52,490 --> 00:20:57,970
em seguida, dentro aqui vamos fazer um passport.authenticate para o local.

252
00:20:57,970 --> 00:21:02,930
E esta autenticação passará de volta, para que possamos fornecer uma função de retorno de chamada para isso.

253
00:21:02,930 --> 00:21:06,810
E essa função de retorno de chamada retornará o erro, o usuário ou

254
00:21:06,810 --> 00:21:08,370
as informações aqui.

255
00:21:08,370 --> 00:21:13,220
E assim, se ele fizer um erro, vamos apenas permitir que o manipulador

256
00:21:13,220 --> 00:21:14,560
de erros expresso para cuidar disso.

257
00:21:14,560 --> 00:21:20,580
Se o usuário for nulo, isso significa que o logon do usuário não teve êxito,

258
00:21:20,580 --> 00:21:25,090
e a razão para isso estará nas informações para que passará de volta como

259
00:21:25,090 --> 00:21:30,660
o erro de informações na mensagem de plano aqui.

260
00:21:30,660 --> 00:21:37,190
Se chegarmos a este ponto, o usuário é verificado com sucesso.

261
00:21:37,190 --> 00:21:38,898
Então, vamos fazer login no usuário.

262
00:21:38,898 --> 00:21:43,850
Assim, o passport.authenticate irá adicionar neste método chamado Login para

263
00:21:43,850 --> 00:21:51,090
a mensagem de solicitação, para que possamos chamar o login com o usuário e

264
00:21:51,090 --> 00:21:56,760
se isso retornar um erro, então vamos retornar o erro aqui adequadamente.

265
00:21:56,760 --> 00:22:01,400
Se não, então teríamos chegado ao ponto em que o usuário é

266
00:22:01,400 --> 00:22:06,560
autenticado com sucesso para que ele possa gerar o token da Web JSON aqui e retornar o

267
00:22:06,560 --> 00:22:12,020
token da Web JSON ao usuário para confirmar se o usuário está registrado com êxito.

268
00:22:12,020 --> 00:22:15,190
Então esse é o conjunto de passos que vamos usar aqui.

269
00:22:15,190 --> 00:22:19,910
Agora, a razão pela qual eu faço uma maneira mais elaborada de lidar com isso é que eu quero

270
00:22:19,910 --> 00:22:24,760
distinguir entre a situação em que um erro genuíno ocorre durante

271
00:22:24,760 --> 00:22:30,700
o processo de aplicação, em oposição à situação em que o nome de usuário é inválido,

272
00:22:30,700 --> 00:22:32,830
ou a senha é inválida.

273
00:22:32,830 --> 00:22:37,713
Então esses dois casos serão tratados por esta situação em que a informação vai

274
00:22:37,713 --> 00:22:40,129
levar a informação de volta para nós.

275
00:22:40,129 --> 00:22:44,551
Então isso não é um erro perse, mas isso é uma situação em que

276
00:22:44,551 --> 00:22:49,440
o usuário não é um usuário válido ou a senha do usuário não é válida.

277
00:22:49,440 --> 00:22:54,880
Então é assim que eles vão lidar com o processo de login do usuário.

278
00:22:54,880 --> 00:22:59,666
Além disso, vou adicionar em mais um método aqui chamado,

279
00:23:05,730 --> 00:23:08,832
CheckJWToken.

280
00:23:08,832 --> 00:23:12,831
É bem possível que, enquanto o cliente efetuou login e

281
00:23:12,831 --> 00:23:18,229
obteve o token da Web JSON, algum tempo mais tarde, o JSON Web Token pode expirar.

282
00:23:18,229 --> 00:23:23,776
Portanto, se o usuário tentar acessar do lado do cliente com um token expirado

283
00:23:23,776 --> 00:23:29,159
para o servidor, o servidor não será capaz de autenticar o usuário.

284
00:23:29,159 --> 00:23:34,024
Então, em intervalos periódicos, podemos querer cruzar a verificação para ter certeza de que o

285
00:23:34,024 --> 00:23:35,733
token da web JSON ainda é válido.

286
00:23:35,733 --> 00:23:41,180
Então, essa é a razão pela qual eu estou incluindo outro endpoint chamado

287
00:23:41,180 --> 00:23:46,131
CheckJWTToken, por isso, se você fizer um chegar ao CheckJWTToken.

288
00:23:46,131 --> 00:23:50,927
Ao incluir o token no cabeçalho de autorização

289
00:23:50,927 --> 00:23:55,926
, essa chamada retornará um verdadeiro ou falso para indicar

290
00:23:55,926 --> 00:24:00,125
se o token da Web JSON ainda é válido ou não.

291
00:24:00,125 --> 00:24:04,430
Se não for válido, o lado do cliente pode iniciar outro login para Para que

292
00:24:04,430 --> 00:24:09,710
o usuário obtenha um novo token da Web JSON, se necessário.

293
00:24:09,710 --> 00:24:15,470
Então, para fazer isso, vamos dizer cors, corsWithOptions e,

294
00:24:19,500 --> 00:24:23,760
req, res, aqui, como esperado.

295
00:24:25,510 --> 00:24:28,029
E aqui vamos dizer,

296
00:24:31,852 --> 00:24:40,983
passport.authenticate ('jwt',

297
00:24:42,356 --> 00:24:49,886
E, {session: false}).

298
00:24:54,050 --> 00:24:59,322
E isso iria retornar err, usuário, informações.

299
00:25:03,010 --> 00:25:07,005
Lembre-se de como usamos o autenticador do Passaporte mais cedo.

300
00:25:07,005 --> 00:25:11,050
Então a sessão JWT cai aqui.

301
00:25:11,050 --> 00:25:14,759
Então, mais cedo aqui dizemos, passaporte.autenticar local.

302
00:25:14,759 --> 00:25:17,039
Então isso é para a autenticação local.

303
00:25:17,039 --> 00:25:21,038
Então isso é para a autenticação de token da Web JSON.

304
00:25:21,038 --> 00:25:26,303
Então, quando chamamos isso, então, uma vez que isso vai verificar o token da web JSON,

305
00:25:26,303 --> 00:25:33,820
então eu vou dizer, se (err), retornar próximo (err).

306
00:25:33,820 --> 00:25:38,540
E, em seguida, deixe o manipulador de erros Express cuidar dessa situação.

307
00:25:38,540 --> 00:25:42,895
E então vamos dizer, se (! usuário),

308
00:25:47,340 --> 00:25:53,395
Se o usuário não existir, então da mesma forma, senão.

309
00:25:53,395 --> 00:25:58,850
Então, o que significa que se o objeto de usuário foi encontrado a partir do token da Web JSON e

310
00:25:58,850 --> 00:26:04,764
depois carregado no req.user, isso significa que o usuário é um usuário válido.

311
00:26:04,764 --> 00:26:06,990
E assim pode ser permitido avançar.

312
00:26:06,990 --> 00:26:13,770
Caso contrário, vamos dizer que o usuário não existe.

313
00:26:13,770 --> 00:26:18,480
Então precisamos inferir que o token da web JSON expirou.

314
00:26:18,480 --> 00:26:24,495
Então, neste ponto, enviaremos uma reserva com o código de status de,

315
00:26:29,070 --> 00:26:31,580
401, então não autorizado.

316
00:26:33,847 --> 00:26:40,570
SetHeader (, 'Content-Type',

317
00:26:42,865 --> 00:26:45,940
'application/json').

318
00:26:45,940 --> 00:26:52,243
E então vamos retornar res,

319
00:26:54,894 --> 00:27:00,970
.json, vamos dizer, {status:,

320
00:27:04,165 --> 00:27:07,131
'JWT invalid! '.

321
00:27:07,131 --> 00:27:15,242
E então devolveremos uma bandeira chamada sucesso: falso.

322
00:27:15,242 --> 00:27:20,624
E, em seguida, Vamos retornar as informações que

323
00:27:20,624 --> 00:27:26,890
obtemos se o usuário não é autenticado como o erro neste ponto.

324
00:27:30,450 --> 00:27:36,219
Caso contrário, isso significa que chegamos a este ponto quando o usuário é um usuário válido.

325
00:27:36,219 --> 00:27:40,921
Então, neste caso, deixe-me apenas copiar esse código aqui,

326
00:27:40,921 --> 00:27:45,392
estaremos enviando um código de status de 200, e

327
00:27:45,392 --> 00:27:48,727
então o res.json enviará JWT,

328
00:27:51,140 --> 00:27:55,050
válido! , e o sucesso será verdadeiro.

329
00:27:56,550 --> 00:28:03,290
E a terceira parte, enviaremos as informações do usuário.

330
00:28:03,290 --> 00:28:07,776
Dessa forma, quando esse endpoint é chamado

331
00:28:07,776 --> 00:28:12,710
com o método get, então isso verificará se o token é válido ou não.

332
00:28:12,710 --> 00:28:15,580
Se o token for válido, você receberá esta resposta.

333
00:28:15,580 --> 00:28:17,311
E a partir do sinalizador de sucesso na resposta,

334
00:28:17,311 --> 00:28:20,050
você pode verificar se o token da Web JSON é válido ou não.

335
00:28:20,050 --> 00:28:24,010
E isso é útil no lado do cliente.

336
00:28:24,010 --> 00:28:30,012
Agora este passaporte aqui, passaporte.autenticar aqui,

337
00:28:30,012 --> 00:28:37,720
terá que ser fornecido com req e res como os dois parâmetros aqui.

338
00:28:37,720 --> 00:28:41,320
Então é assim que chamamos esse passaporte. Autenticar.

339
00:28:41,320 --> 00:28:45,060
Observe que sempre que você chamar passport.authenticate e

340
00:28:45,060 --> 00:28:49,917
esperar essa função de retorno de chamada aqui, você precisa anexar este ponto, req,

341
00:28:49,917 --> 00:28:53,973
.res, a esse passport.authenticate e, em seguida, de volta aqui.

342
00:28:53,973 --> 00:28:57,915
Então, com isso, nós atualizamos tudo no lado do servidor.

343
00:28:57,915 --> 00:29:01,900
Então vamos salvar todas as alterações no lado do servidor.

344
00:29:01,900 --> 00:29:05,400
Então agora o nosso servidor está pronto para

345
00:29:05,400 --> 00:29:10,680
lidar com os pedidos recebidos do nosso cliente Angular.

346
00:29:10,680 --> 00:29:13,120
Com isso, completamos este exercício.

347
00:29:13,120 --> 00:29:18,010
Neste exercício, preparamos nosso servidor Express para

348
00:29:18,010 --> 00:29:22,930
lidar com solicitações recebidas de nosso cliente Angular.

349
00:29:22,930 --> 00:29:26,890
No próximo exercício, vamos olhar para o cliente Angular com mais detalhes para

350
00:29:26,890 --> 00:29:32,350
entender como ele está se comunicando com este servidor extra.

351
00:29:32,350 --> 00:29:37,881
Este é um bom momento para você fazer um commit Git com a mensagem,

352
00:29:37,881 --> 00:29:40,932
integrando cliente e servidor.

353
00:29:40,932 --> 00:29:44,825
[ MUSIC]