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

2
00:00:04,614 --> 00:00:09,792
Avevamo già sviluppato un server API REST completo usando Express e

3
00:00:09,792 --> 00:00:12,026
MongoDB come parte di questo corso.

4
00:00:12,026 --> 00:00:16,881
Affinché il server sia in grado di comunicare in modo significativo con il nostro cliente,

5
00:00:16,881 --> 00:00:21,892
faremo alcune piccole modifiche ad esso in modo che restituisca il giusto tipo di dati.

6
00:00:21,892 --> 00:00:26,063
In modo che la nostra implementazione client possa funzionare in modo più efficiente

7
00:00:26,063 --> 00:00:29,370
con i dati restituiti dal nostro lato server.

8
00:00:29,370 --> 00:00:30,427
Quindi, per farlo,

9
00:00:30,427 --> 00:00:35,724
lavoriamo su alcuni aggiustamenti al nostro lato server in questo esercizio.

10
00:00:37,478 --> 00:00:43,220
Andando al nostro server nell'editor, prima di iniziare a lavorare sul server,

11
00:00:43,220 --> 00:00:48,497
ti suggerisco di scaricare tutte le immagini che ho fornito

12
00:00:48,497 --> 00:00:53,260
come file zip nelle risorse di esercizio chiamate images.zip.

13
00:00:53,260 --> 00:00:56,530
Decomprimere il file e quindi ottenere tutte le immagini da lì, e

14
00:00:56,530 --> 00:01:03,440
quindi copiare quelle immagini nella cartella immagini pubbliche nel nostro server.

15
00:01:03,440 --> 00:01:08,980
Quindi vedi che qui ho

16
00:01:08,980 --> 00:01:10,580
già copiato tutte le immagini nella mia cartella di immagini pubbliche qui.

17
00:01:10,580 --> 00:01:15,120
Perché il nostro server è quello che servirà tutte queste immagini per la

18
00:01:15,120 --> 00:01:17,460
nostra applicazione client.

19
00:01:17,460 --> 00:01:22,820
Successivamente, andiamo ai cors e aggiustiamo quella whitelist, qui.

20
00:01:22,820 --> 00:01:27,919
Quindi, per la nostra applicazione client Angular, se la avviamo

21
00:01:27,919 --> 00:01:33,571
con il comando ng serve, viene eseguito in localhost: 4200.

22
00:01:33,571 --> 00:01:36,196
Quindi qualsiasi richiesta proveniente dalla nostra

23
00:01:36,196 --> 00:01:40,750
applicazione Angular al server lo porterà come origine lì.

24
00:01:40,750 --> 00:01:44,710
Ecco perché ho intenzione di aggiungerlo nella mia whitelist, in modo

25
00:01:44,710 --> 00:01:50,310
che eventuali problemi cors vengano risolti automaticamente.

26
00:01:50,310 --> 00:01:54,848
Quindi andando in quel file cors.js,

27
00:01:54,848 --> 00:01:59,698
nella mia whitelist, qui, lasciami aggiungere

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

29
00:02:08,371 --> 00:02:12,503
E questa è l'origine da cui tutto il mio client Angular

30
00:02:12,503 --> 00:02:16,690
originerà la richiesta che arriva a questo server.

31
00:02:16,690 --> 00:02:22,020
In questo modo, i miei cors non causeranno problemi per il client angolare di maggio.

32
00:02:22,020 --> 00:02:27,760
Successivamente, abbiamo bisogno di aggiornare alcuni dei percorsi per gestire

33
00:02:27,760 --> 00:02:32,760
i parametri di query e anche alcuni piccoli altri aggiustamenti.

34
00:02:32,760 --> 00:02:35,905
Permettetemi di iniziare con i file promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
Quindi questo è semplice da aggiornare.

36
00:02:39,760 --> 00:02:44,790
Quindi andando al file promoRouter.js, nel file PromorOuter, per

37
00:02:44,790 --> 00:02:47,960
la richiesta get che arriviamo qui,

38
00:02:47,960 --> 00:02:52,400
invece di fare promotions.Find con un JavaScript vuoto,

39
00:02:52,400 --> 00:02:57,256
qui vorrei fornire il req.query come

40
00:02:57,256 --> 00:03:02,470
parametro a quel promotions.Find qui.

41
00:03:02,470 --> 00:03:07,650
Stessa cosa anche con LeaderRouter, quindi lasciami andare al file leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
E anche in LeaderRouter,

43
00:03:09,786 --> 00:03:14,642
qui dove trovi Leaders.Find con l'oggetto JavaScript vuoto.

44
00:03:14,642 --> 00:03:18,423
Invece, sostituirlo con quel req.query, in modo

45
00:03:18,423 --> 00:03:21,852
che i parametri della query vengano passati.

46
00:03:21,852 --> 00:03:26,430
Quindi questo è dove passeremo nella colonna in primo piano

47
00:03:26,430 --> 00:03:29,487
attraverso come parametro di query.

48
00:03:29,487 --> 00:03:34,678
Ora dopo aver regolato questi due, lavoriamo ora sul percorso piatto,

49
00:03:34,678 --> 00:03:41,090
quindi andando al file dishRouter.js, anche nel DishRouter, lo stesso aggiornamento qui.

50
00:03:41,090 --> 00:03:48,920
Quindi andando a questo piatti.Find nel metodo get qui, cambialo in req.query.

51
00:03:48,920 --> 00:03:52,987
Quindi con questo, il mio aggiornamento DishRouter è stato completato.

52
00:03:52,987 --> 00:03:57,664
Quindi ora abbiamo aggiornato il PromorOuter, il ReaderRouter e

53
00:03:57,664 --> 00:04:02,784
il DishRouter, quindi passeremo ad aggiornare quel FavoriteRouter.

54
00:04:02,784 --> 00:04:07,519
Ora avresti implementato il router preferito come parte del tuo

55
00:04:07,519 --> 00:04:09,500
quarto incarico.

56
00:04:09,500 --> 00:04:12,306
Ora nel FavoriteRouter, vedrai che per

57
00:04:12,306 --> 00:04:16,618
il FavoriteRouter non ti sto mostrando la parte rimanente perché

58
00:04:16,618 --> 00:04:19,437
avresti dovuto fare come parte del tuo incarico.

59
00:04:19,437 --> 00:04:22,925
Permettetemi di attirare la vostra attenzione

60
00:04:22,925 --> 00:04:26,422
sul metodo get per FavoriteRouter.route («/:dishid').

61
00:04:26,422 --> 00:04:31,161
Ora, userò questo metodo get

62
00:04:31,161 --> 00:04:35,653
per verificare che il piatto specifico con

63
00:04:35,653 --> 00:04:40,292
un dishId sia già uno dei preferiti per l'utente.

64
00:04:40,292 --> 00:04:44,413
Quindi, invece di dire semplicemente l'operazione GET non supportata,

65
00:04:44,413 --> 00:04:48,879
ho solo intenzione di sfruttare la presenza di questa operazione get.

66
00:04:48,879 --> 00:04:52,574
E poi diremo,

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

68
00:04:56,684 --> 00:04:59,843
E dirò,

69
00:04:59,843 --> 00:05:04,952
utente: req.user.id.

70
00:05:04,952 --> 00:05:10,194
Quindi troveremo i preferiti per quel particolare utente.

71
00:05:10,194 --> 00:05:20,166
E poi diremo, .then, preferiti.

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

73
00:05:35,757 --> 00:05:40,160
next (err)).

74
00:05:40,160 --> 00:05:45,638
E poi allo stesso modo qui, aggiungeremo l'errore qui.

75
00:05:48,689 --> 00:05:50,239
Avanti (err)), qui.

76
00:05:50,239 --> 00:05:55,689
Quindi all'interno di questo.then, quando otteniamo i favoriti,

77
00:05:55,689 --> 00:06:00,290
allora controlleremo, se (! preferiti).

78
00:06:00,290 --> 00:06:04,500
Quindi, se non ci sono preferiti per questo utente,

79
00:06:04,500 --> 00:06:08,770
allora ovviamente il piatto che stiamo controllando non esiste.

80
00:06:08,770 --> 00:06:18,604
Quindi torneremo, 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 poi torneremo,

84
00:06:42,997 --> 00:06:51,490
dicendo, «esiste»: falso.

85
00:06:51,490 --> 00:06:56,891
Quindi quello che stiamo specificando qui è che se il get è fatto

86
00:06:56,891 --> 00:07:02,771
a questo endpoint con un dishId, questo flag esiste qui

87
00:07:02,771 --> 00:07:07,826
sarà impostato su true se questo piatto fa parte dei miei preferiti.

88
00:07:07,826 --> 00:07:13,008
Se questo piatto non fa parte dei miei preferiti, imposterò il flag esiste su false.

89
00:07:13,008 --> 00:07:16,687
Quindi qui, vedi che dal momento che non ho alcun favorito, quindi

90
00:07:16,687 --> 00:07:20,008
esiste dovrebbe essere automaticamente falso a questo punto.

91
00:07:20,008 --> 00:07:26,780
Quindi diremo «esiste»: falso, e poi restituiremo i preferiti, qui.

92
00:07:28,950 --> 00:07:31,237
Beh, ovviamente in questo caso,

93
00:07:31,237 --> 00:07:35,225
i favoriti sarebbero nulli a questo punto, altrimenti.

94
00:07:39,097 --> 00:07:42,779
Quindi il che significa che i favoriti non sono nulli, quindi diremo se,

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

96
00:07:52,688 --> 00:07:58,011
quindi stiamo andando a cercare req.params.

97
00:08:00,046 --> 00:08:02,620
DishID, quindi stiamo andando a cercare questo.

98
00:08:02,620 --> 00:08:09,632
favorites.dishes.array, per vedere se esiste piatto lì dentro.

99
00:08:09,632 --> 00:08:15,410
E se non esiste, ovviamente questo restituirà un indice negativo qui.

100
00:08:15,410 --> 00:08:20,200
Quindi anche in questo caso, restituirò esattamente lo stesso di qui.

101
00:08:20,200 --> 00:08:22,291
Quindi, se restituisce un indice negativo,

102
00:08:22,291 --> 00:08:26,990
significa che anche se questo particolare utente ha un centro preferito.

103
00:08:26,990 --> 00:08:31,464
Questo piatto specifico non esiste nella lista il

104
00:08:31,464 --> 00:08:36,987
suo preferito, quindi è per questo che restituirà esistono false qui.

105
00:08:36,987 --> 00:08:45,119
Ora altrimenti ciò significa che il piatto esiste nella lista dei preferiti.

106
00:08:45,119 --> 00:08:51,352
Quindi in questo caso, restituirò il codice di stato 200 esiste è vero.

107
00:08:51,352 --> 00:08:57,144
In questo modo quando l'utente esegue un'operazione get su

108
00:08:57,144 --> 00:09:02,408
questo punto finale con /favorite/dishId.

109
00:09:02,408 --> 00:09:07,265
Dove il dishId viene fornito come parametro qui.

110
00:09:07,265 --> 00:09:09,821
Come il parametro record qui,

111
00:09:09,821 --> 00:09:15,226
allora controlleremo per vedere se quel piatto esiste nei preferiti.

112
00:09:15,226 --> 00:09:19,983
Se nessuno dei preferiti esiste per questo utente, allora restituiremo un falso esistere.

113
00:09:19,983 --> 00:09:22,138
Allo stesso modo, se i preferiti esistono,

114
00:09:22,138 --> 00:09:27,000
ma quel piatto particolare non esiste nei preferiti, restituirà un falso.

115
00:09:27,000 --> 00:09:28,705
Altrimenti restituirà un vero.

116
00:09:28,705 --> 00:09:33,890
Quindi questa bandiera esiste può essere utilizzata dal mio cliente

117
00:09:33,890 --> 00:09:41,997
per verificare se questo piatto fa parte della lista dei piatti preferiti per questo utente o meno.

118
00:09:41,997 --> 00:09:48,624
Infine aggiorneremo il file users.js.

119
00:09:48,624 --> 00:09:53,284
Ora nel file users.js, dobbiamo aggiungere in

120
00:09:53,284 --> 00:09:58,204
un altro campo router.options qui perché

121
00:09:58,204 --> 00:10:03,769
a volte una richiesta Post come hai visto con il login,

122
00:10:03,769 --> 00:10:10,760
invieremo prima le opzioni per verificare, specialmente con le auto,

123
00:10:10,760 --> 00:10:16,140
se la richiesta di post sarà consentita.

124
00:10:16,140 --> 00:10:23,156
Ecco perché controlleranno le auto, le auto con opzioni qui e poi.

125
00:10:26,156 --> 00:10:27,915
Restituiremo semplicemente

126
00:10:34,203 --> 00:10:39,938
un messaggio di stato di 200 in risposta a questo.

127
00:10:39,938 --> 00:10:44,624
Quindi per qualsiasi endpoint sotto gli utenti se abbiamo ricevuto

128
00:10:44,624 --> 00:10:50,183
le opzioni restituirà semplicemente uno stato 200 qui.

129
00:10:50,183 --> 00:10:57,417
Ora la funzione Login che avevamo implementato in precedenza.

130
00:10:57,417 --> 00:11:02,782
Abbiamo semplicemente fatto passport.authenticate ('local') qui e

131
00:11:02,782 --> 00:11:06,600
poi controlliamo i valori rimanenti qui.

132
00:11:06,600 --> 00:11:11,006
Ora questo passport.authenticate ('local'), se l'utente non viene

133
00:11:11,006 --> 00:11:15,221
autenticato, restituisce semplicemente un non autorizzato nel messaggio di risposta.

134
00:11:15,221 --> 00:11:18,212
Ora questo potrebbe non essere molto significativo per

135
00:11:18,212 --> 00:11:21,868
il lato client visualizzare queste informazioni.

136
00:11:21,868 --> 00:11:27,245
Ecco perché miglioreremo questo metodo di login post router in modo

137
00:11:27,245 --> 00:11:35,158
tale che l'autenticazione restituirà informazioni più significative in questa parte.

138
00:11:35,158 --> 00:11:39,831
Quindi, per farlo, non faremo l'

139
00:11:39,831 --> 00:11:43,120
autenticazione del passaporto qui dentro.

140
00:11:43,120 --> 00:11:47,180
Invece, prenderemo, quindi lasciami rimuovere da lì,

141
00:11:47,180 --> 00:11:52,410
e poi vedrai come aggiornerò il post del router qui.

142
00:11:52,410 --> 00:11:56,520
Quindi vedremo AutosWithOptions.

143
00:11:56,520 --> 00:12:03,806
E poi includeremo il req, res e il prossimo qui.

144
00:12:03,806 --> 00:12:08,216
E all'interno del req, res, e il

145
00:12:08,216 --> 00:12:14,227
prossimo qui, passport.authenticate,

146
00:12:17,271 --> 00:12:22,035
lo chiameremo con 'local'.

147
00:12:22,035 --> 00:12:27,041
Ora, quando chiamiamo questo con local, se

148
00:12:27,041 --> 00:12:34,607
si verifica un errore di autenticazione, passport.authenticate può essere fatto per restituire il valore di errore,

149
00:12:34,607 --> 00:12:39,519
e inoltre restituirà l'utente se non ci sono errori.

150
00:12:39,519 --> 00:12:42,283
E potrebbe parametro chiamato info,

151
00:12:42,283 --> 00:12:47,643
che porterà informazioni aggiuntive che potrebbero essere passate all'utente.

152
00:12:47,643 --> 00:12:51,714
Questo errore verrà restituito quando si verifica un errore autentico che si verifica

153
00:12:51,714 --> 00:12:53,590
nel possibile per l'autenticazione.

154
00:12:53,590 --> 00:12:58,995
Ma se le informazioni dell'utente vengono inviate a passport.authenticate ma

155
00:12:58,995 --> 00:13:03,945
l'utente non esiste, allora non viene conteggiato come un errore.

156
00:13:03,945 --> 00:13:07,828
Invece, verrà conteggiato come utente non esiste.

157
00:13:07,828 --> 00:13:12,825
E quell'informazione viene passata di nuovo nell'oggetto info che entra in.

158
00:13:12,825 --> 00:13:16,793
Quindi l'errore verrà restituito quando c'è un errore genuino che si verifica durante

159
00:13:16,793 --> 00:13:18,405
il processo di autenticazione.

160
00:13:18,405 --> 00:13:23,995
Ma le informazioni, conterranno informazioni se l'utente non esiste e quindi

161
00:13:23,995 --> 00:13:30,102
passport.authenticate sta passando un messaggio che dice che l'utente non

162
00:13:30,102 --> 00:13:35,780
esiste o che il nome utente non è corretto o che la password non è corretta.

163
00:13:35,780 --> 00:13:40,415
E così via, in modo che le informazioni vengano trasmesse, nel messaggio info.

164
00:13:40,415 --> 00:13:44,569
Ora, vedremo come questo è utile per noi quando guardiamo il lato cliente un

165
00:13:44,569 --> 00:13:45,990
po 'più tardi.

166
00:13:45,990 --> 00:13:48,070
Quindi, in questa situazione,

167
00:13:49,530 --> 00:13:55,110
gestiremo questo come segue.

168
00:13:55,110 --> 00:14:00,510
E non solo, quando chiamiamo questo passaporto autenticare,

169
00:14:00,510 --> 00:14:04,976
abbiamo anche bisogno di passare in un (req, res,

170
00:14:04,976 --> 00:14:08,550
next) come quella striscia di tre parametri.

171
00:14:08,550 --> 00:14:10,320
Quindi questa è la struttura.

172
00:14:10,320 --> 00:14:13,558
Quando hai bisogno di chiamare l'autenticazione del passaporto,

173
00:14:13,558 --> 00:14:18,798
aspettati che ti trasmetta informazioni come questa come metodo di richiamo qui.

174
00:14:18,798 --> 00:14:24,072
Quindi è anche necessario fornire questo req, res prossimo anche lì.

175
00:14:24,072 --> 00:14:25,720
Ora, se questo dovesse accadere.

176
00:14:25,720 --> 00:14:30,206
Quindi diremo se (err).

177
00:14:30,206 --> 00:14:34,163
Quindi, se si verifica un errore,

178
00:14:34,163 --> 00:14:39,781
diremo ritorno successivo (err) e quindi lasciare che il

179
00:14:39,781 --> 00:14:45,028
gestore degli errori del nostro router espresso si occupi di questo.

180
00:14:45,028 --> 00:14:48,365
Ora, prenderemo in considerazione altre situazioni.

181
00:14:48,365 --> 00:14:53,484
Se (! ), quindi se abbiamo raggiunto questo punto significa che

182
00:14:53,484 --> 00:14:59,232
non è stato un errore che si è verificato, ma invece forse l'utente non è stato trovato.

183
00:14:59,232 --> 00:15:04,860
Se l'utente non viene trovato, l'utente qui verrà impostato su null in questo caso.

184
00:15:04,860 --> 00:15:10,088
Quindi, in quella situazione se l'utente non esiste,

185
00:15:10,088 --> 00:15:17,068
allora dobbiamo essere in grado di passare le informazioni sul lato server.

186
00:15:17,068 --> 00:15:22,895
Quindi quello che faremo è passeremo in queste informazioni in questo formato,

187
00:15:22,895 --> 00:15:26,576
quindi ho intenzione di tagliare questo fuori da qui, e

188
00:15:26,576 --> 00:15:30,491
poi incollarlo qui e poi modificheremo così.

189
00:15:30,491 --> 00:15:36,748
Se l'utente è nullo, allora invieremo indietro uno StatusCode

190
00:15:36,748 --> 00:15:41,509
di 401 che significa non autorizzato, e

191
00:15:41,509 --> 00:15:47,640
poi invieremo indietro informazioni di successo, falso.

192
00:15:47,640 --> 00:15:54,340
E poi non passeremo indietro il token, passeremo indietro il messaggio di stato.

193
00:15:54,340 --> 00:16:02,501
Quindi qui diremo login, Non riuscito.

194
00:16:02,501 --> 00:16:07,870
E poi la terza informazione passerà queste informazioni,

195
00:16:07,870 --> 00:16:13,238
quell'oggetto che abbiamo ricevuto qui come terza parte in

196
00:16:13,238 --> 00:16:19,231
quel messaggio di risposta che inviamo indietro dal nostro server qui.

197
00:16:19,231 --> 00:16:22,496
Quindi il flag di successo verrà ripristinato su false.

198
00:16:22,496 --> 00:16:27,145
Lo stato verrà impostato Accesso non riuscito e le informazioni di errore,

199
00:16:27,145 --> 00:16:30,235
che viene passato nelle informazioni verranno restituite.

200
00:16:30,235 --> 00:16:34,788
Ora si noti che questa situazione si verificherà se il nome utente e

201
00:16:34,788 --> 00:16:36,789
la password non sono corretti.

202
00:16:36,789 --> 00:16:42,516
E quindi questo non è un errore, nel senso di errore, ma il fatto che l'autenticazione

203
00:16:42,516 --> 00:16:47,505
non sia riuscita a trovare l'utente o la password dell'utente non è corretto.

204
00:16:47,505 --> 00:16:51,545
In modo che le informazioni vengano codificate nell'afflusso che arriva, e in modo

205
00:16:51,545 --> 00:16:58,227
che io possa tornare come errore al mio lato client.

206
00:16:58,227 --> 00:17:02,633
Altrimenti parte viene

207
00:17:02,633 --> 00:17:08,810
gestita come REQ.login.

208
00:17:08,810 --> 00:17:10,700
Quindi, se questo ha successo,

209
00:17:10,700 --> 00:17:16,200
passport.authenticate aggiungerà questo metodo chiamato REQ.login all'utente.

210
00:17:16,200 --> 00:17:21,400
Quindi a questo punto passeremo solo l'oggetto utente che abbiamo ottenuto.

211
00:17:21,400 --> 00:17:26,398
Quindi qui, se abbiamo raggiunto questo punto,

212
00:17:26,398 --> 00:17:32,572
allora ciò significa che l'oggetto utente non è nullo e

213
00:17:32,572 --> 00:17:37,717
anche nessun errore si è verificato, quindi ciò significa che

214
00:17:37,717 --> 00:17:43,304
l'utente può essere loggato e quindi diremo err.

215
00:17:43,304 --> 00:17:44,995
Quindi cercherà di accedere all'utente.

216
00:17:44,995 --> 00:17:47,231
Quindi diremo se err.

217
00:17:51,210 --> 00:17:58,260
E poi passeremo indietro lo stesso tipo di informazioni di errore che abbiamo fatto qui.

218
00:17:59,450 --> 00:18:02,317
Quindi, in questo caso, se l'errore.

219
00:18:06,077 --> 00:18:11,757
In caso di errore, allora passeremo indietro il codice di stato 401 e

220
00:18:11,757 --> 00:18:18,970
diremo che il successo è falso e lo stato è Login Unsuccessed.

221
00:18:18,970 --> 00:18:24,359
E poi le informazioni di errore

222
00:18:24,359 --> 00:18:29,539
passeremo questo come invece di

223
00:18:29,539 --> 00:18:36,810
informazioni passeremo in non poteva accedere utente.

224
00:18:36,810 --> 00:18:42,580
Quindi questo è il messaggio che passerà qui, se si verifica l'errore.

225
00:18:42,580 --> 00:18:46,195
Altrimenti, saremmo qui sotto.

226
00:18:46,195 --> 00:18:53,157
E così a questo punto saremmo in grado di generare il token.

227
00:18:53,157 --> 00:18:57,594
Quindi, se abbiamo raggiunto fino a questo punto, significa che l'utente ha

228
00:18:57,594 --> 00:19:01,892
effettuato correttamente l'accesso e quindi ora possiamo generare il token.

229
00:19:01,892 --> 00:19:07,009
Quindi genereremo il token in base all'ID utente e

230
00:19:07,009 --> 00:19:11,794
poi passeremo indietro quel token all'utente.

231
00:19:11,794 --> 00:19:15,462
Quindi qui diremo token var.

232
00:19:15,462 --> 00:19:22,789
E poi possiamo dire res.statusCode = 200, e quindi res.json (successo) è vero, il

233
00:19:22,789 --> 00:19:26,999
che significa che l'utente ha effettuato correttamente l'accesso.

234
00:19:26,999 --> 00:19:31,842
E così lo stato sarebbe Login riuscito, e

235
00:19:31,842 --> 00:19:39,900
quindi la terza parte invece dell'errore passerò il token all'utente.

236
00:19:39,900 --> 00:19:45,590
Quindi diremo token, token,

237
00:19:45,590 --> 00:19:50,390
questo token che abbiamo appena ottenuto in precedenza, in modo che al token venga passato

238
00:19:50,390 --> 00:19:54,600
come proprietà token del messaggio di luce rip.

239
00:19:54,600 --> 00:19:57,910
Quindi qui, si noti che questo asse è impostato su true.

240
00:19:57,910 --> 00:20:01,890
Quindi, il che significa che l'utente ha effettuato correttamente l'accesso.

241
00:20:01,890 --> 00:20:05,660
E così l'utente può procedere in avanti a questo punto.

242
00:20:05,660 --> 00:20:13,667
E questo deve essere fatto all'interno del REQ.login qui.

243
00:20:13,667 --> 00:20:20,640
Quindi a questo punto chiuderemo il REQ.login.

244
00:20:20,640 --> 00:20:27,570
Quindi nota che questo è all'interno di questo REQ.Login qui.

245
00:20:27,570 --> 00:20:30,830
Quindi lì dentro passeremo questi tre indietro.

246
00:20:30,830 --> 00:20:33,800
Quindi lasciatemi solo indent trese tre righe in.

247
00:20:35,830 --> 00:20:42,490
E così è così che gestiremmo il login degli utenti.

248
00:20:42,490 --> 00:20:45,850
Quindi di nuovo, rivedere questo codice ancora una volta.

249
00:20:45,850 --> 00:20:47,740
Quindi faremo post router, ma

250
00:20:47,740 --> 00:20:52,490
invece di fare l'autenticazione passaporto proprio lì, diremo req, res,

251
00:20:52,490 --> 00:20:57,970
prossimo e poi dentro qui faremo un passport.authenticate per il locale.

252
00:20:57,970 --> 00:21:02,930
E questo autenticazione passerà indietro, quindi possiamo fornire una funzione di callback a quello.

253
00:21:02,930 --> 00:21:06,810
E questa funzione di callback restituirà l'errore, l'utente o

254
00:21:06,810 --> 00:21:08,370
le informazioni qui.

255
00:21:08,370 --> 00:21:13,220
E quindi, se fa un errore, permetteremo solo al gestore di errori espresso

256
00:21:13,220 --> 00:21:14,560
di occuparsi di questo.

257
00:21:14,560 --> 00:21:20,580
Se l'utente è nullo, significa che l'accesso dell'utente non è riuscito

258
00:21:20,580 --> 00:21:25,090
e il motivo sarà nelle informazioni in modo che verrà restituito come

259
00:21:25,090 --> 00:21:30,660
errore di informazioni nel messaggio del piano qui.

260
00:21:30,660 --> 00:21:37,190
Se arriviamo a questo punto, l'utente viene verificato con successo.

261
00:21:37,190 --> 00:21:38,898
Quindi effettueremo il login all'utente.

262
00:21:38,898 --> 00:21:43,850
Quindi il passport.authenticate aggiungerà questo metodo chiamato Login

263
00:21:43,850 --> 00:21:51,090
al messaggio di richiesta, in modo da poter chiamare il login con l'utente e

264
00:21:51,090 --> 00:21:56,760
se questo restituisce un errore, allora restituiremo l'errore qui in modo appropriato.

265
00:21:56,760 --> 00:22:01,400
In caso contrario, avremmo raggiunto il punto in cui l'utente è stato

266
00:22:01,400 --> 00:22:06,560
autenticato correttamente in modo che possano generare il token Web JSON qui e restituire il

267
00:22:06,560 --> 00:22:12,020
token Web JSON all'utente per confermare che l'utente è stato registrato correttamente.

268
00:22:12,020 --> 00:22:15,190
Quindi questo è l'insieme di passi che useremo qui.

269
00:22:15,190 --> 00:22:19,910
Ora il motivo per cui faccio un modo più elaborato di gestirlo è che voglio

270
00:22:19,910 --> 00:22:24,760
distinguere tra la situazione in cui si verifica un errore genuino durante

271
00:22:24,760 --> 00:22:30,700
il processo di applicazione, in contrasto con la situazione in cui il nome utente non è valido

272
00:22:30,700 --> 00:22:32,830
o la password non è valida.

273
00:22:32,830 --> 00:22:37,713
Quindi questi due casi saranno gestiti da questa situazione in cui le informazioni

274
00:22:37,713 --> 00:22:40,129
porteranno le informazioni a noi.

275
00:22:40,129 --> 00:22:44,551
Quindi non è un errore perse, ma questa è una situazione in cui

276
00:22:44,551 --> 00:22:49,440
l'utente non è un utente valido o la password dell'utente non è valida.

277
00:22:49,440 --> 00:22:54,880
Quindi è così che gestiranno il processo di accesso dell'utente.

278
00:22:54,880 --> 00:22:59,666
Inoltre, aggiungerò un altro metodo qui chiamato,

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

280
00:23:08,832 --> 00:23:12,831
È del tutto possibile che mentre il client ha effettuato l'accesso e

281
00:23:12,831 --> 00:23:18,229
ottenuto il token Web JSON, in un secondo momento, il token Web JSON potrebbe scadere.

282
00:23:18,229 --> 00:23:23,776
Quindi, se l'utente tenta di accedere dal lato client con un token scaduto

283
00:23:23,776 --> 00:23:29,159
al server, il server non sarà in grado di autenticare l'utente.

284
00:23:29,159 --> 00:23:34,024
Quindi a intervalli periodici potremmo desiderare di controllare incrociando per assicurarci che il

285
00:23:34,024 --> 00:23:35,733
token web JSON sia ancora valido.

286
00:23:35,733 --> 00:23:41,180
Quindi questo è il motivo per cui sto includendo un altro endpoint chiamato

287
00:23:41,180 --> 00:23:46,131
CheckJWttoken, quindi se fai un get a checkJWttoken.

288
00:23:46,131 --> 00:23:50,927
Includendo il token nell'intestazione di autorizzazione,

289
00:23:50,927 --> 00:23:55,926
questa chiamata restituirà un true o false per indicare

290
00:23:55,926 --> 00:24:00,125
se il token web JSON è ancora valido o meno.

291
00:24:00,125 --> 00:24:04,430
Se non è valido, il lato client può avviare un altro login per Per

292
00:24:04,430 --> 00:24:09,710
l'utente ottenere un nuovo token Web JSON, se necessario.

293
00:24:09,710 --> 00:24:15,470
Quindi per fare questo, diremo cors, corsWithOptions e,

294
00:24:19,500 --> 00:24:23,760
req, res, qui, come previsto.

295
00:24:25,510 --> 00:24:28,029
E qui diremo,

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 questo restituirebbe err, utente, informazioni.

299
00:25:03,010 --> 00:25:07,005
Quindi ricordate come abbiamo usato l'autenticatore Passport prima.

300
00:25:07,005 --> 00:25:11,050
Quindi la sessione JWT cade qui.

301
00:25:11,050 --> 00:25:14,759
Quindi prima qui diciamo, passport.authenticate locale.

302
00:25:14,759 --> 00:25:17,039
Quindi questo è per l'autenticazione locale.

303
00:25:17,039 --> 00:25:21,038
Quindi questo è per l'autenticazione del token web JSON.

304
00:25:21,038 --> 00:25:26,303
Quindi, quando lo chiamiamo, quindi, dal momento che questo sta per verificare il token web JSON,

305
00:25:26,303 --> 00:25:33,820
quindi ho intenzione di dire, se (err), tornare next (err).

306
00:25:33,820 --> 00:25:38,540
E poi lascia che il gestore degli errori Express si occupi di quella situazione.

307
00:25:38,540 --> 00:25:42,895
E poi diremo, se (! ),

308
00:25:47,340 --> 00:25:53,395
Se l'utente non esiste, allo stesso modo, altrimenti.

309
00:25:53,395 --> 00:25:58,850
Quindi, il che significa che se l'oggetto utente è stato trovato dal token web JSON e

310
00:25:58,850 --> 00:26:04,764
quindi caricato su req.user, significa che l'utente è un utente valido.

311
00:26:04,764 --> 00:26:06,990
E così può essere permesso di procedere avanti.

312
00:26:06,990 --> 00:26:13,770
Altrimenti, diremo che l'utente non esiste.

313
00:26:13,770 --> 00:26:18,480
Quindi dobbiamo dedurre che il token web JSON è scaduto.

314
00:26:18,480 --> 00:26:24,495
Quindi, a questo punto, invieremo una riserva con il codice di stato,

315
00:26:29,070 --> 00:26:31,580
401, quindi non autorizzato.

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 poi restituiremo res,

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

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

321
00:27:07,131 --> 00:27:15,242
E poi restituiremo una bandiera chiamata successo: falso.

322
00:27:15,242 --> 00:27:20,624
E poi, Restituiremo le informazioni che

323
00:27:20,624 --> 00:27:26,890
otteniamo se l'utente non è autenticato come l'errore a questo punto.

324
00:27:30,450 --> 00:27:36,219
In caso contrario, ciò significa che raggiungiamo questo punto quando l'utente è un utente valido.

325
00:27:36,219 --> 00:27:40,921
Quindi, in questo caso, lasciami copiare quel codice qui,

326
00:27:40,921 --> 00:27:45,392
invieremo un codice di stato di 200, e

327
00:27:45,392 --> 00:27:48,727
quindi il res.json invierà JWT,

328
00:27:51,140 --> 00:27:55,050
valido! , e il successo sarà vero.

329
00:27:56,550 --> 00:28:03,290
E la terza parte, invieremo le informazioni dell'utente. In

330
00:28:03,290 --> 00:28:07,776
questo modo, quando questo endpoint viene chiamato

331
00:28:07,776 --> 00:28:12,710
con il metodo get, questo verificherà se il token è valido o meno.

332
00:28:12,710 --> 00:28:15,580
Se il token è valido, riceverai questa risposta.

333
00:28:15,580 --> 00:28:17,311
E dal flag di successo nella risposta,

334
00:28:17,311 --> 00:28:20,050
puoi verificare se il token web JSON è valido o meno.

335
00:28:20,050 --> 00:28:24,010
E questo è utile sul lato client.

336
00:28:24,010 --> 00:28:30,012
Ora questo passaporto qui, passport.authenticate qui,

337
00:28:30,012 --> 00:28:37,720
dovrà essere fornito con req e res come i due parametri qui.

338
00:28:37,720 --> 00:28:41,320
Quindi è così che chiamiamo quel passport.authenticate.

339
00:28:41,320 --> 00:28:45,060
Si noti che ogni volta che si chiama passport.authenticate e

340
00:28:45,060 --> 00:28:49,917
si aspetta questa funzione di callback qui, è necessario aggiungere questo punto, req,

341
00:28:49,917 --> 00:28:53,973
.res, a quel passport.authenticate, e poi di nuovo qui.

342
00:28:53,973 --> 00:28:57,915
Quindi con questo, abbiamo aggiornato tutto sul lato server.

343
00:28:57,915 --> 00:29:01,900
Quindi salviamo tutte le modifiche sul lato server.

344
00:29:01,900 --> 00:29:05,400
Quindi ora il nostro server è pronto a

345
00:29:05,400 --> 00:29:10,680
gestire le richieste in arrivo dal nostro client Angular.

346
00:29:10,680 --> 00:29:13,120
Con questo, completiamo questo esercizio.

347
00:29:13,120 --> 00:29:18,010
In questo esercizio, abbiamo ora preparato il nostro server Express per

348
00:29:18,010 --> 00:29:22,930
gestire le richieste in arrivo dal nostro client Angular.

349
00:29:22,930 --> 00:29:26,890
Nel prossimo esercizio, vedremo il client Angular in modo più dettagliato per

350
00:29:26,890 --> 00:29:32,350
capire come sta comunicando con questo server aggiuntivo.

351
00:29:32,350 --> 00:29:37,881
Questo è un buon momento per fare un commit Git con il messaggio,

352
00:29:37,881 --> 00:29:40,932
integrando client e server.

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