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

2
00:00:04,614 --> 00:00:09,792
Ya habíamos desarrollado un servidor API REST completo usando Express y

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

4
00:00:12,026 --> 00:00:16,881
Para que el servidor pueda comunicarse de manera significativa con nuestro cliente,

5
00:00:16,881 --> 00:00:21,892
haremos algunos ajustes menores para que devuelva el tipo correcto de datos.

6
00:00:21,892 --> 00:00:26,063
Para que la implementación de nuestros clientes pueda trabajar de manera más eficiente

7
00:00:26,063 --> 00:00:29,370
con los datos devueltos desde nuestro lado del servidor.

8
00:00:29,370 --> 00:00:30,427
Así que para hacer eso,

9
00:00:30,427 --> 00:00:35,724
trabajemos en algunos ajustes a nuestro lado del servidor en este ejercicio.

10
00:00:37,478 --> 00:00:43,220
Ir a nuestro servidor en el editor, antes de comenzar a trabajar en el servidor,

11
00:00:43,220 --> 00:00:48,497
le sugiero que descargue todas las imágenes que he proporcionado

12
00:00:48,497 --> 00:00:53,260
como un archivo zip en los recursos del ejercicio llamados images.zip.

13
00:00:53,260 --> 00:00:56,530
Descomprima el archivo y luego obtenga todas las imágenes desde allí, y

14
00:00:56,530 --> 00:01:03,440
luego copie esas imágenes en la carpeta de imágenes públicas en nuestro servidor.

15
00:01:03,440 --> 00:01:08,980
Así que ves que aquí he copiado todas las imágenes en mi

16
00:01:08,980 --> 00:01:10,580
carpeta de imágenes públicas aquí ya.

17
00:01:10,580 --> 00:01:15,120
Porque nuestro servidor es el que va a servir todas estas imágenes para

18
00:01:15,120 --> 00:01:17,460
nuestra aplicación cliente.

19
00:01:17,460 --> 00:01:22,820
A continuación, vamos a los cors y ajustamos esa lista blanca, aquí.

20
00:01:22,820 --> 00:01:27,919
Entonces, para nuestra aplicación cliente angular, si la iniciamos

21
00:01:27,919 --> 00:01:33,571
con el comando ng serve, se ejecuta en localhost: 4200.

22
00:01:33,571 --> 00:01:36,196
Por lo tanto, cualquier solicitud que llegue desde nuestra

23
00:01:36,196 --> 00:01:40,750
aplicación angular al servidor llevará eso como su origen allí.

24
00:01:40,750 --> 00:01:44,710
Así que es por eso que voy a agregar eso en mi lista blanca, para

25
00:01:44,710 --> 00:01:50,310
que cualquier problema cors se solucione automáticamente.

26
00:01:50,310 --> 00:01:54,848
Así que entrando en ese archivo cors.js,

27
00:01:54,848 --> 00:01:59,698
en mi lista blanca, aquí, permítanme agregar en

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

29
00:02:08,371 --> 00:02:12,503
Y este es el origen desde el cual todo mi cliente angular

30
00:02:12,503 --> 00:02:16,690
originará la solicitud que viene a este servidor.

31
00:02:16,690 --> 00:02:22,020
Así que de esa manera, mis cors no causarán problemas para mayo cliente angular.

32
00:02:22,020 --> 00:02:27,760
A continuación, necesitamos actualizar algunas de las rutas para manejar

33
00:02:27,760 --> 00:02:32,760
los parámetros de consulta, y también algunos otros ajustes menores.

34
00:02:32,760 --> 00:02:35,905
Permítanme comenzar con los archivos promoRouter.js.

35
00:02:35,905 --> 00:02:39,760
Así que es fácil actualizarse.

36
00:02:39,760 --> 00:02:44,790
Así que yendo al archivo promoRouter.js, en el archivo PromoRouter, para

37
00:02:44,790 --> 00:02:47,960
la solicitud get que obtenemos aquí,

38
00:02:47,960 --> 00:02:52,400
en lugar de hacer promotions.Find con un JavaScript vacío,

39
00:02:52,400 --> 00:02:57,256
aquí proporcionaría el req.query como

40
00:02:57,256 --> 00:03:02,470
parámetro para que promotions.Find aquí.

41
00:03:02,470 --> 00:03:07,650
Lo mismo con el LeaderRouter también, así que déjame ir al archivo leaderRouter.js.

42
00:03:07,650 --> 00:03:09,786
Y en LeaderRouter también,

43
00:03:09,786 --> 00:03:14,642
aquí donde encontrará Leaders.Find con el objeto JavaScript vacío.

44
00:03:14,642 --> 00:03:18,423
En su lugar, reemplace eso con ese req.query, para

45
00:03:18,423 --> 00:03:21,852
que se pasen los parámetros de consulta.

46
00:03:21,852 --> 00:03:26,430
Así que aquí es donde pasaremos la columna destacada

47
00:03:26,430 --> 00:03:29,487
como el parámetro de consulta.

48
00:03:29,487 --> 00:03:34,678
Ahora habiendo ajustado estos dos, ahora trabajemos en la ruta del plato,

49
00:03:34,678 --> 00:03:41,090
así que vamos al archivo dishRouter.js, incluso en el DishRouter, la misma actualización aquí.

50
00:03:41,090 --> 00:03:48,920
Así que ir a este plate.Find en el método get aquí, cambie eso a req.query.

51
00:03:48,920 --> 00:03:52,987
Entonces, con esto, mi actualización de DishRouter se ha completado.

52
00:03:52,987 --> 00:03:57,664
Así que ahora hemos actualizado el PromoRouter, el ReaderRouter, y

53
00:03:57,664 --> 00:04:02,784
el DishRouter, entonces vamos a pasar a actualizar ese FavoriterOuter.

54
00:04:02,784 --> 00:04:07,519
Ahora habría implementado el router favorito como parte de su

55
00:04:07,519 --> 00:04:09,500
cuarta asignación.

56
00:04:09,500 --> 00:04:12,306
Ahora en FavorIterOuter, verá que para

57
00:04:12,306 --> 00:04:16,618
FavorIterOuter no le estoy mostrando el parter restante porque

58
00:04:16,618 --> 00:04:19,437
debería haber hecho como parte de su asignación.

59
00:04:19,437 --> 00:04:22,925
Permítanme primero llamar su atención sobre el método get para

60
00:04:22,925 --> 00:04:26,422
Favoriterouter.route («/:dishid').

61
00:04:26,422 --> 00:04:31,161
Ahora, voy a usar este método get

62
00:04:31,161 --> 00:04:35,653
para verificar que el plato específico con

63
00:04:35,653 --> 00:04:40,292
un DishiD ya sea un favorito para el usuario.

64
00:04:40,292 --> 00:04:44,413
Entonces, en lugar de simplemente decir que la operación GET no es compatible,

65
00:04:44,413 --> 00:04:48,879
solo voy a aprovechar la presencia de esta operación get.

66
00:04:48,879 --> 00:04:52,574
Y luego vamos a decir,

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

68
00:04:56,684 --> 00:04:59,843
Y diré,

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

70
00:05:04,952 --> 00:05:10,194
Así que encontraremos los favoritos para ese usuario en particular.

71
00:05:10,194 --> 00:05:20,166
Y luego diremos, .entonces, favoritos.

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

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

74
00:05:40,160 --> 00:05:45,638
Y luego de manera similar aquí, agregaremos el error aquí.

75
00:05:48,689 --> 00:05:50,239
Siguiente (err)), aquí.

76
00:05:50,239 --> 00:05:55,689
Así que dentro de esto .then, cuando obtengamos los favoritos,

77
00:05:55,689 --> 00:06:00,290
entonces verificaremos, si (! favoritos).

78
00:06:00,290 --> 00:06:04,500
Por lo tanto, si no hay favoritos para este usuario,

79
00:06:04,500 --> 00:06:08,770
entonces obviamente el plato que estamos comprobando no existe.

80
00:06:08,770 --> 00:06:18,604
Así que regresaremos, 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
Y luego volveremos,

84
00:06:42,997 --> 00:06:51,490
Decir, «existe»: falso.

85
00:06:51,490 --> 00:06:56,891
Entonces, lo que estamos especificando aquí es que si el get se hace

86
00:06:56,891 --> 00:07:02,771
a este punto final con un DishiD, esta bandera existe aquí

87
00:07:02,771 --> 00:07:07,826
se establecerá en true si este plato es parte de mis favoritos.

88
00:07:07,826 --> 00:07:13,008
Si este plato no es parte de mis favoritos, estableceré la bandera existe en falso.

89
00:07:13,008 --> 00:07:16,687
Así que aquí, ves que dado que no tengo ningún favorito, por lo que

90
00:07:16,687 --> 00:07:20,008
existe debería ser automáticamente falso en este punto.

91
00:07:20,008 --> 00:07:26,780
Entonces diremos «existe»: falso, y luego devolveremos los favoritos, aquí.

92
00:07:28,950 --> 00:07:31,237
Bueno, obviamente en este caso,

93
00:07:31,237 --> 00:07:35,225
los favoritos serían nulos en este punto, de lo contrario.

94
00:07:39,097 --> 00:07:42,779
Entonces, lo que significa que los favoritos no son nulos, así que diremos if,

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

96
00:07:52,688 --> 00:07:58,011
así que vamos a buscar req.params.

97
00:08:00,046 --> 00:08:02,620
Deshid, así que vamos a buscar esto.

98
00:08:02,620 --> 00:08:09,632
Favorites.dishes.array, para ver si el plato existe allí.

99
00:08:09,632 --> 00:08:15,410
Y si no existe, obviamente esto devolverá un índice negativo aquí.

100
00:08:15,410 --> 00:08:20,200
Así que en ese caso también, volveré exactamente lo mismo que aquí.

101
00:08:20,200 --> 00:08:22,291
Entonces, si devuelve un índice negativo,

102
00:08:22,291 --> 00:08:26,990
entonces eso significa que a pesar de que este usuario en particular tiene un centro favorito.

103
00:08:26,990 --> 00:08:31,464
Este plato específico no existe en la lista de

104
00:08:31,464 --> 00:08:36,987
su favorito, así que es por eso que va a volver existir falso aquí.

105
00:08:36,987 --> 00:08:45,119
Ahora de lo contrario eso significa que el plato existe en la lista de favoritos.

106
00:08:45,119 --> 00:08:51,352
Entonces, en este caso, devolveré el código de estado 200 existe es verdadero.

107
00:08:51,352 --> 00:08:57,144
Así, cuando el usuario realiza una operación get en

108
00:08:57,144 --> 00:09:02,408
este punto final con el /favorite/dishid.

109
00:09:02,408 --> 00:09:07,265
Donde se suministra el DISHID como parámetro aquí.

110
00:09:07,265 --> 00:09:09,821
Como parámetro de registros aquí,

111
00:09:09,821 --> 00:09:15,226
entonces vamos a comprobar si ese plato existe en los favoritos.

112
00:09:15,226 --> 00:09:19,983
Si ninguno de los favoritos existe para este usuario, entonces devolveremos un false.

113
00:09:19,983 --> 00:09:22,138
Del mismo modo, si los favoritos existen,

114
00:09:22,138 --> 00:09:27,000
pero ese plato en particular no existe en los favoritos, entonces devolverá un falso.

115
00:09:27,000 --> 00:09:28,705
De lo contrario, devolverá un verdadero.

116
00:09:28,705 --> 00:09:33,890
Así que esta bandera existe puede ser utilizada por mi cliente

117
00:09:33,890 --> 00:09:41,997
para comprobar si este plato es parte de la lista de platos favoritos para este usuario o no.

118
00:09:41,997 --> 00:09:48,624
Finalmente actualizaremos el archivo users.js.

119
00:09:48,624 --> 00:09:53,284
Ahora en el archivo users.js, tenemos que agregar

120
00:09:53,284 --> 00:09:58,204
otro campo router.options aquí porque a

121
00:09:58,204 --> 00:10:03,769
veces una solicitud de publicación como vio con el inicio de sesión,

122
00:10:03,769 --> 00:10:10,760
vamos a enviar las opciones primero para comprobar, especialmente con los coches,

123
00:10:10,760 --> 00:10:16,140
si la solicitud de publicación será permitida.

124
00:10:16,140 --> 00:10:23,156
Así que es por eso que revisarán coches, coches con opciones aquí y después.

125
00:10:26,156 --> 00:10:27,915
Simplemente devolveremos

126
00:10:34,203 --> 00:10:39,938
un mensaje de estado de 200 en respuesta a eso.

127
00:10:39,938 --> 00:10:44,624
Por lo tanto, para cualquier endpoint bajo los usuarios si recibimos

128
00:10:44,624 --> 00:10:50,183
las opciones simplemente devolverá un estado 200 aquí.

129
00:10:50,183 --> 00:10:57,417
Ahora la función de inicio de sesión que habíamos implementado anteriormente.

130
00:10:57,417 --> 00:11:02,782
Simplemente hemos hecho passport.authenticate ('local') aquí y

131
00:11:02,782 --> 00:11:06,600
luego comprobamos los valores restantes aquí.

132
00:11:06,600 --> 00:11:11,006
Ahora este passport.authenticate ('local'), si el usuario no se

133
00:11:11,006 --> 00:11:15,221
autentica simplemente devuelve un mensaje no autorizado en el mensaje de respuesta.

134
00:11:15,221 --> 00:11:18,212
Ahora eso puede no ser muy significativo para

135
00:11:18,212 --> 00:11:21,868
el lado del cliente para mostrar esta información.

136
00:11:21,868 --> 00:11:27,245
Así que es por eso que vamos a mejorar este método de inicio de sesión después del enrutador para

137
00:11:27,245 --> 00:11:35,158
que la autenticación devuelva información más significativa en esta parte.

138
00:11:35,158 --> 00:11:39,831
Así que para hacer eso, no vamos a hacer que el pasaporte se

139
00:11:39,831 --> 00:11:43,120
autentique aquí dentro.

140
00:11:43,120 --> 00:11:47,180
En su lugar, tomaremos, así que permítanme eliminarlo de allí,

141
00:11:47,180 --> 00:11:52,410
y luego verán cómo actualizaré la publicación del enrutador aquí.

142
00:11:52,410 --> 00:11:56,520
Así que veremos cochesWithOptions.

143
00:11:56,520 --> 00:12:03,806
Y luego incluiremos el req, res y el siguiente aquí.

144
00:12:03,806 --> 00:12:08,216
Y dentro de la req, res, y el

145
00:12:08,216 --> 00:12:14,227
siguiente aquí, passport.authenticate,

146
00:12:17,271 --> 00:12:22,035
Vamos a llamar a esto con 'local'.

147
00:12:22,035 --> 00:12:27,041
Ahora, cuando llamamos a esto con local, si

148
00:12:27,041 --> 00:12:34,607
se produce un error de autenticación, se puede hacer passport.authenticate para devolver el valor del error,

149
00:12:34,607 --> 00:12:39,519
y también devolverá al usuario si no hay error.

150
00:12:39,519 --> 00:12:42,283
Y podría ser un parámetro llamado info,

151
00:12:42,283 --> 00:12:47,643
que llevará información adicional que podría ser transmitida de nuevo al usuario.

152
00:12:47,643 --> 00:12:51,714
Este error se devuelve cuando hay un error genuino que se produce en

153
00:12:51,714 --> 00:12:53,590
la posible autenticación.

154
00:12:53,590 --> 00:12:58,995
Pero si la información del usuario se envía a passport.authenticate pero

155
00:12:58,995 --> 00:13:03,945
el usuario no existe, entonces eso no se cuenta como un error.

156
00:13:03,945 --> 00:13:07,828
En su lugar, se contará como el usuario no existe.

157
00:13:07,828 --> 00:13:12,825
Y esa información se transmite de nuevo en el objeto info que entra.

158
00:13:12,825 --> 00:13:16,793
Por lo tanto, el error se devolverá cuando haya un error genuino que ocurre durante

159
00:13:16,793 --> 00:13:18,405
el proceso de autenticación.

160
00:13:18,405 --> 00:13:23,995
Pero la información contendrá información si el usuario no existe y, por lo tanto,

161
00:13:23,995 --> 00:13:30,102
passport.authenticate está devolviendo un mensaje diciendo que el usuario no

162
00:13:30,102 --> 00:13:35,780
existe o que el nombre de usuario es incorrecto o la contraseña es incorrecta.

163
00:13:35,780 --> 00:13:40,415
Y así sucesivamente, para que la información se transmita en, en el mensaje de información.

164
00:13:40,415 --> 00:13:44,569
Ahora, veremos cómo esto es útil para nosotros cuando miremos el lado del cliente un

165
00:13:44,569 --> 00:13:45,990
poco más tarde.

166
00:13:45,990 --> 00:13:48,070
Así que en esta situación,

167
00:13:49,530 --> 00:13:55,110
manejaremos esto de la siguiente manera.

168
00:13:55,110 --> 00:14:00,510
Y no solo eso, cuando llamamos a este pasaporte autenticar,

169
00:14:00,510 --> 00:14:04,976
también necesitamos pasar un (req, res,

170
00:14:04,976 --> 00:14:08,550
next) como esa tira de tres parámetros.

171
00:14:08,550 --> 00:14:10,320
Así que esta es la estructura.

172
00:14:10,320 --> 00:14:13,558
Cuando necesite llamar a la autenticación de pasaporte,

173
00:14:13,558 --> 00:14:18,798
espere que le transmita información como esta como un método de devolución de llamada aquí.

174
00:14:18,798 --> 00:14:24,072
Así que también necesita suministrar este req, res el siguiente justo allí también.

175
00:14:24,072 --> 00:14:25,720
Ahora, si esto ocurre.

176
00:14:25,720 --> 00:14:30,206
Así que diremos si (err).

177
00:14:30,206 --> 00:14:34,163
Entonces, si ocurre un error,

178
00:14:34,163 --> 00:14:39,781
diremos return next (err) y luego dejaremos que el

179
00:14:39,781 --> 00:14:45,028
manejador de errores de nuestro enrutador express se encargue de eso.

180
00:14:45,028 --> 00:14:48,365
Ahora, consideraremos otras situaciones.

181
00:14:48,365 --> 00:14:53,484
Si (! ), por lo que si hemos llegado a este punto, eso significa que

182
00:14:53,484 --> 00:14:59,232
no fue un error que ocurrió, sino que quizás no se pudo encontrar al usuario.

183
00:14:59,232 --> 00:15:04,860
Si el usuario no se encuentra entonces el usuario aquí se establecerá como nulo en este caso.

184
00:15:04,860 --> 00:15:10,088
Entonces, en esa situación si el usuario no existe,

185
00:15:10,088 --> 00:15:17,068
entonces necesitamos poder pasar información al lado del servidor.

186
00:15:17,068 --> 00:15:22,895
Así que lo que haremos es pasar esta información en este formato,

187
00:15:22,895 --> 00:15:26,576
así que voy a cortar esto desde aquí, y

188
00:15:26,576 --> 00:15:30,491
luego pegarlo aquí y luego lo editaremos.

189
00:15:30,491 --> 00:15:36,748
Si el usuario es nulo, entonces enviaremos de vuelta un

190
00:15:36,748 --> 00:15:41,509
StatusCode 401 que significa no autorizado, y

191
00:15:41,509 --> 00:15:47,640
luego devolveremos la información de éxito, falso.

192
00:15:47,640 --> 00:15:54,340
Y luego no vamos a pasar de nuevo el token, vamos a pasar de nuevo el mensaje de estado.

193
00:15:54,340 --> 00:16:02,501
Así que aquí vamos a decir inicio de sesión, sin éxito.

194
00:16:02,501 --> 00:16:07,870
Y luego la tercera información pasará esta información,

195
00:16:07,870 --> 00:16:13,238
ese objeto que recibimos aquí como la tercera parte de

196
00:16:13,238 --> 00:16:19,231
ese mensaje de respuesta que enviamos de vuelta desde nuestro servidor aquí.

197
00:16:19,231 --> 00:16:22,496
Por lo tanto, el indicador de éxito se restablecerá a false.

198
00:16:22,496 --> 00:16:27,145
El estado se establecerá Iniciar sesión sin éxito y la información de error,

199
00:16:27,145 --> 00:16:30,235
que se pasa en la información se pasará de nuevo.

200
00:16:30,235 --> 00:16:34,788
Ahora tenga en cuenta que esta situación ocurrirá si el nombre de usuario y

201
00:16:34,788 --> 00:16:36,789
la contraseña son incorrectos.

202
00:16:36,789 --> 00:16:42,516
Y por lo tanto, esto no es un error, en el sentido del error, pero el hecho de que el autenticado

203
00:16:42,516 --> 00:16:47,505
no pudo encontrar el usuario o la contraseña del usuario es incorrecto.

204
00:16:47,505 --> 00:16:51,545
Así que esa información será codificada en la entrada que entra, y así

205
00:16:51,545 --> 00:16:58,227
voy a pasar de nuevo como un error al lado de mi cliente.

206
00:16:58,227 --> 00:17:02,633
De lo contrario, parte se

207
00:17:02,633 --> 00:17:08,810
maneja como req.login.

208
00:17:08,810 --> 00:17:10,700
Por lo tanto, si esto es exitoso,

209
00:17:10,700 --> 00:17:16,200
passport.authenticate agregará este método llamado req.login al usuario.

210
00:17:16,200 --> 00:17:21,400
Así que en este punto simplemente pasaremos el objeto de usuario que hemos obtenido.

211
00:17:21,400 --> 00:17:26,398
Así que aquí, si hemos llegado a este punto,

212
00:17:26,398 --> 00:17:32,572
entonces eso significa que el objeto de usuario no es nulo y

213
00:17:32,572 --> 00:17:37,717
tampoco se produjo ningún error, por lo que significa que

214
00:17:37,717 --> 00:17:43,304
el usuario puede iniciar sesión y por lo que decimos err.

215
00:17:43,304 --> 00:17:44,995
Por lo tanto, intentará iniciar sesión con el usuario.

216
00:17:44,995 --> 00:17:47,231
Así que diremos si erran.

217
00:17:51,210 --> 00:17:58,260
Y luego pasaremos el mismo tipo de información de error que hicimos aquí.

218
00:17:59,450 --> 00:18:02,317
Entonces, en este caso, si el error.

219
00:18:06,077 --> 00:18:11,757
Si se produce un error, pasaremos el código de estado 401 y

220
00:18:11,757 --> 00:18:18,970
diremos que el éxito es falso y el estado es Iniciar sesión sin éxito.

221
00:18:18,970 --> 00:18:24,359
Y luego la información de error

222
00:18:24,359 --> 00:18:29,539
vamos a pasar esto ya que en lugar de

223
00:18:29,539 --> 00:18:36,810
información que vamos a pasar no pudo iniciar sesión usuario.

224
00:18:36,810 --> 00:18:42,580
Entonces ese es el mensaje que pasará aquí, si se produce el error.

225
00:18:42,580 --> 00:18:46,195
De lo contrario, estaríamos abajo aquí abajo.

226
00:18:46,195 --> 00:18:53,157
Y entonces en este punto seríamos capaces de generar el token.

227
00:18:53,157 --> 00:18:57,594
Así que si hemos llegado hasta este punto eso significa que el usuario ha

228
00:18:57,594 --> 00:19:01,892
iniciado sesión con éxito y por lo tanto ahora podemos generar el token.

229
00:19:01,892 --> 00:19:07,009
Por lo tanto, generaremos el token basado en el ID de usuario y

230
00:19:07,009 --> 00:19:11,794
luego devolveremos ese token al usuario.

231
00:19:11,794 --> 00:19:15,462
Así que aquí vamos a decir var token.

232
00:19:15,462 --> 00:19:22,789
Y luego podemos decir Res.statusCode = 200, y luego res.json (éxito) es verdadero,

233
00:19:22,789 --> 00:19:26,999
lo que significa que el usuario inició sesión con éxito.

234
00:19:26,999 --> 00:19:31,842
Y entonces el estado sería Inicio de sesión exitoso, y

235
00:19:31,842 --> 00:19:39,900
luego la tercera parte en lugar del error, pasaré el token de nuevo al usuario.

236
00:19:39,900 --> 00:19:45,590
Así que diremos token, token,

237
00:19:45,590 --> 00:19:50,390
este token que acabamos de obtener antes, de modo que a token se pasará

238
00:19:50,390 --> 00:19:54,600
como la propiedad token del mensaje de luz de rip.

239
00:19:54,600 --> 00:19:57,910
Así que aquí, observe que este eje está establecido en true.

240
00:19:57,910 --> 00:20:01,890
Entonces, lo que significa que el usuario inició sesión con éxito.

241
00:20:01,890 --> 00:20:05,660
Y así el usuario puede seguir adelante en este punto.

242
00:20:05,660 --> 00:20:13,667
Y esto tiene que hacerse dentro del req.login aquí.

243
00:20:13,667 --> 00:20:20,640
Así que en este punto vamos a cerrar el req.login.

244
00:20:20,640 --> 00:20:27,570
Así que note que esto está dentro de este req.login aquí.

245
00:20:27,570 --> 00:20:30,830
Así que ahí dentro pasaremos estos tres de vuelta.

246
00:20:30,830 --> 00:20:33,800
Así que déjame sangrar tres líneas.

247
00:20:35,830 --> 00:20:42,490
Y así es como manejaríamos el inicio de sesión de los usuarios.

248
00:20:42,490 --> 00:20:45,850
Así que de nuevo, revisando este código una vez más.

249
00:20:45,850 --> 00:20:47,740
Así que haremos la publicación del enrutador, pero

250
00:20:47,740 --> 00:20:52,490
en lugar de hacer la autenticación del pasaporte justo allí, diremos req, res,

251
00:20:52,490 --> 00:20:57,970
siguiente y luego dentro de aquí haremos un pasaporte.authenticate para el local.

252
00:20:57,970 --> 00:21:02,930
Y esta autenticación pasará de nuevo, por lo que podemos proporcionar una función de devolución de llamada a eso.

253
00:21:02,930 --> 00:21:06,810
Y esta función de devolución de llamada devolverá el error, el usuario o

254
00:21:06,810 --> 00:21:08,370
la información aquí.

255
00:21:08,370 --> 00:21:13,220
Por lo tanto, si se produce un error, permitiremos que el manejador de errores expresos se

256
00:21:13,220 --> 00:21:14,560
encargue de eso.

257
00:21:14,560 --> 00:21:20,580
Si el usuario es nulo, eso significa que el inicio de sesión del usuario no tuvo éxito,

258
00:21:20,580 --> 00:21:25,090
y el motivo de eso estará en la información, por lo que pasará como

259
00:21:25,090 --> 00:21:30,660
el error de información en el mensaje del plan aquí.

260
00:21:30,660 --> 00:21:37,190
Si llegamos a este punto, el usuario se verifica con éxito.

261
00:21:37,190 --> 00:21:38,898
Entonces iniciaremos sesión al usuario.

262
00:21:38,898 --> 00:21:43,850
Así que el passport.authenticate agregará este método llamado Login

263
00:21:43,850 --> 00:21:51,090
al mensaje de solicitud, por lo que podemos llamar al inicio de sesión con el usuario y

264
00:21:51,090 --> 00:21:56,760
si esto devuelve un error, entonces devolveremos el error aquí apropiadamente.

265
00:21:56,760 --> 00:22:01,400
Si no, entonces habríamos llegado al punto en el que el usuario se

266
00:22:01,400 --> 00:22:06,560
autentica correctamente para que pueda generar el token web JSON aquí y devolver el

267
00:22:06,560 --> 00:22:12,020
token web JSON al usuario para confirmar que el usuario se ha registrado correctamente.

268
00:22:12,020 --> 00:22:15,190
Así que ese es el conjunto de pasos que vamos a usar aquí.

269
00:22:15,190 --> 00:22:19,910
Ahora, la razón por la que hago una forma más elaborada de manejarlo es que quiero

270
00:22:19,910 --> 00:22:24,760
distinguir entre la situación en la que ocurre un error genuino durante

271
00:22:24,760 --> 00:22:30,700
el proceso de solicitud, a diferencia de la situación en la que el nombre de usuario no es válido,

272
00:22:30,700 --> 00:22:32,830
o la contraseña no es válida.

273
00:22:32,830 --> 00:22:37,713
Así que esos dos casos serán manejados por esta situación en la que la información

274
00:22:37,713 --> 00:22:40,129
nos llevará la información de vuelta.

275
00:22:40,129 --> 00:22:44,551
Así que eso no es un error perse, pero esa es una situación en

276
00:22:44,551 --> 00:22:49,440
la que el usuario no es un usuario válido o la contraseña del usuario no es válida.

277
00:22:49,440 --> 00:22:54,880
Así es como manejarán el proceso de inicio de sesión del usuario.

278
00:22:54,880 --> 00:22:59,666
Además, agregaré un método más aquí llamado,

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

280
00:23:08,832 --> 00:23:12,831
Es muy posible que mientras el cliente haya iniciado sesión y

281
00:23:12,831 --> 00:23:18,229
obtenido el token web JSON, en algún momento más tarde, el token web JSON puede caducar.

282
00:23:18,229 --> 00:23:23,776
Por lo tanto, si el usuario intenta acceder desde el lado del cliente con un token caducado

283
00:23:23,776 --> 00:23:29,159
al servidor, entonces el servidor no podrá autenticar al usuario.

284
00:23:29,159 --> 00:23:34,024
Por lo tanto, a intervalos periódicos, es posible que desee realizar una comprobación cruzada para asegurarnos de que el

285
00:23:34,024 --> 00:23:35,733
token web JSON siga siendo válido.

286
00:23:35,733 --> 00:23:41,180
Entonces, esa es la razón por la que estoy incluyendo otro punto final llamado

287
00:23:41,180 --> 00:23:46,131
CheckJWTToken, por lo que si haces un llegar al CheckJWTToken.

288
00:23:46,131 --> 00:23:50,927
Al incluir el token en el encabezado de autorización

289
00:23:50,927 --> 00:23:55,926
, esta llamada devolverá un verdadero o falso para indicarle

290
00:23:55,926 --> 00:24:00,125
si el token web JSON sigue siendo válido o no.

291
00:24:00,125 --> 00:24:04,430
Si no es válido, el lado del cliente puede iniciar otro inicio de sesión para

292
00:24:04,430 --> 00:24:09,710
que el usuario obtenga un nuevo token web JSON, si es necesario.

293
00:24:09,710 --> 00:24:15,470
Entonces, para hacer esto, diremos cors, CorsWithOptions y,

294
00:24:19,500 --> 00:24:23,760
req, res, aquí, como se esperaba.

295
00:24:25,510 --> 00:24:28,029
Y aquí vamos a decir,

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

297
00:24:42,356 --> 00:24:49,886
Y, {sesión: false}).

298
00:24:54,050 --> 00:24:59,322
Y esto devolvería err, usuario, información.

299
00:25:03,010 --> 00:25:07,005
Así que recuerde cómo usamos el autenticador de Passport antes.

300
00:25:07,005 --> 00:25:11,050
Así que la sesión de JWT cae aquí.

301
00:25:11,050 --> 00:25:14,759
Así que antes aquí decimos, passport.authenticate local.

302
00:25:14,759 --> 00:25:17,039
Así que esto es para la autenticación local.

303
00:25:17,039 --> 00:25:21,038
Entonces esto es para la autenticación de token web JSON.

304
00:25:21,038 --> 00:25:26,303
Entonces, cuando llamemos a eso, ya que eso va a verificar el token web JSON,

305
00:25:26,303 --> 00:25:33,820
así que voy a decir, si (err), vuelva a continuación (err).

306
00:25:33,820 --> 00:25:38,540
Y luego deje que el controlador de errores Express se ocupe de esa situación.

307
00:25:38,540 --> 00:25:42,895
Y luego diremos, si (! usuario),

308
00:25:47,340 --> 00:25:53,395
Si el usuario no existe, entonces de manera similar, de lo contrario.

309
00:25:53,395 --> 00:25:58,850
Entonces, lo que significa que si el objeto de usuario se encontró desde el token web JSON y

310
00:25:58,850 --> 00:26:04,764
luego se cargó en el req.user, entonces eso significa que el usuario es un usuario válido.

311
00:26:04,764 --> 00:26:06,990
Y así se puede permitir que siga adelante.

312
00:26:06,990 --> 00:26:13,770
De lo contrario, vamos a decir que el usuario no existe.

313
00:26:13,770 --> 00:26:18,480
Por lo tanto, tenemos que inferir que el token web JSON ha caducado.

314
00:26:18,480 --> 00:26:24,495
Así que en este punto, enviaremos una resolución con el código de estado de,

315
00:26:29,070 --> 00:26:31,580
401, tan no 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
Y luego devolveremos res,

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

320
00:27:04,165 --> 00:27:07,131
'JWT inválido! '.

321
00:27:07,131 --> 00:27:15,242
Y luego devolveremos una bandera llamada éxito: falso.

322
00:27:15,242 --> 00:27:20,624
Y luego, Vamos a devolver la información que

323
00:27:20,624 --> 00:27:26,890
obtenemos si el usuario no está autenticado como el error en este punto.

324
00:27:30,450 --> 00:27:36,219
De lo contrario, eso significa que llegamos a este punto cuando el usuario es un usuario válido.

325
00:27:36,219 --> 00:27:40,921
Entonces, en este caso, déjame copiar ese código aquí,

326
00:27:40,921 --> 00:27:45,392
estaremos enviando un código de estado de 200, y

327
00:27:45,392 --> 00:27:48,727
luego el res.json enviará JWT,

328
00:27:51,140 --> 00:27:55,050
¡válido! , y el éxito será cierto.

329
00:27:56,550 --> 00:28:03,290
Y la tercera parte, enviaremos la información del usuario.

330
00:28:03,290 --> 00:28:07,776
De esa manera, cuando se llama a este extremo

331
00:28:07,776 --> 00:28:12,710
con el método get, esto verificará si el token es válido o no.

332
00:28:12,710 --> 00:28:15,580
Si el token es válido, entonces recibirá esta respuesta.

333
00:28:15,580 --> 00:28:17,311
Y desde el indicador de éxito en la respuesta,

334
00:28:17,311 --> 00:28:20,050
puede verificar si el token web JSON es válido o no.

335
00:28:20,050 --> 00:28:24,010
Y esto es útil en el lado del cliente.

336
00:28:24,010 --> 00:28:30,012
Ahora este pasaporte aquí, passport.authenticate aquí,

337
00:28:30,012 --> 00:28:37,720
tendrá que ser suministrado con req y res como los dos parámetros aquí.

338
00:28:37,720 --> 00:28:41,320
Así es como llamamos a ese passport.authenticate.

339
00:28:41,320 --> 00:28:45,060
Observe que cada vez que llame a passport.authenticate y

340
00:28:45,060 --> 00:28:49,917
espere esta función de devolución de llamada aquí, debe anexar este punto, req,

341
00:28:49,917 --> 00:28:53,973
.res, a ese passport.authenticate, y luego volver aquí.

342
00:28:53,973 --> 00:28:57,915
Así que con esto, hemos actualizado todo en el lado del servidor.

343
00:28:57,915 --> 00:29:01,900
Así que vamos a guardar todos los cambios en el lado del servidor.

344
00:29:01,900 --> 00:29:05,400
Así que ahora nuestro servidor está listo para

345
00:29:05,400 --> 00:29:10,680
manejar las solicitudes entrantes de nuestro cliente Angular.

346
00:29:10,680 --> 00:29:13,120
Con esto, completamos este ejercicio.

347
00:29:13,120 --> 00:29:18,010
En este ejercicio, ahora hemos preparado nuestro servidor Express para

348
00:29:18,010 --> 00:29:22,930
manejar las solicitudes entrantes de nuestro cliente Angular.

349
00:29:22,930 --> 00:29:26,890
En el próximo ejercicio, vamos a ver el cliente angular con más detalle para

350
00:29:26,890 --> 00:29:32,350
entender cómo se comunica con este servidor adicional.

351
00:29:32,350 --> 00:29:37,881
Este es un buen momento para que hagas una confirmación de Git con el mensaje,

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

353
00:29:40,932 --> 00:29:44,825
[ MÚSICA]