1
00:00:03,950 --> 00:00:09,180
Ahora que hemos entendido el pasaporte y cómo el pasaporte añade

2
00:00:09,180 --> 00:00:14,294
en un middleware de autenticación simple para nuestra aplicación NodeJS,

3
00:00:14,294 --> 00:00:18,435
y proporciona una

4
00:00:18,435 --> 00:00:22,935
forma flexible fácil de configurar y proporciona varias estrategias para la autenticación de usuarios,

5
00:00:22,935 --> 00:00:27,850
vamos a ir en un viaje con nuestro pasaporte.

6
00:00:27,890 --> 00:00:31,020
Para comenzar en este ejercicio,

7
00:00:31,020 --> 00:00:33,945
como primer paso vamos a instalar los

8
00:00:33,945 --> 00:00:40,135
módulos pasaporte, pasport-local y pasport-local-mangosta en nuestro servidor de confusión.

9
00:00:40,135 --> 00:00:44,030
Así que en el indicador escriba npm instal_passport,

10
00:00:44,030 --> 00:00:49,820
passport-local,

11
00:00:49,820 --> 00:00:59,430
pasaporte local-mangosta mnus menos guardar e instalar estos tres módulos.

12
00:00:59,430 --> 00:01:05,980
Como puede ver en este momento estamos comenzando con las

13
00:01:05,980 --> 00:01:15,004
versiones de pasaporte 0.4.0, pasport-local 1.0.0 y pasport-local-mangosta 5.0.1 en este curso.

14
00:01:15,004 --> 00:01:20,110
Ahora que hemos instalado pasaporte, passport-local y passport-local-mangosta,

15
00:01:20,110 --> 00:01:25,640
vayamos al servidor de confusión y vayamos al archivo user.js.

16
00:01:25,640 --> 00:01:31,325
Vamos a actualizar el esquema de usuario y el modelo para utilizar el pasaport-local-mangosta.

17
00:01:31,325 --> 00:01:33,735
Para hacer eso, aquí vamos a decir

18
00:01:33,735 --> 00:01:41,060
var PassportLocalMongoose

19
00:01:41,060 --> 00:01:45,390
requiere pasaport-local-mangosta.

20
00:01:46,190 --> 00:01:50,330
Así que esto vamos a instalar como

21
00:01:50,330 --> 00:01:56,780
el plugin de mangosta en nuestra aplicación y podemos eliminar el nombre de usuario y

22
00:01:56,780 --> 00:02:00,440
contraseña porque estos serían automáticamente añadidos por

23
00:02:00,440 --> 00:02:04,535
el plugin passport-local-mangosta aquí y

24
00:02:04,535 --> 00:02:12,980
para usarlo como un plugin en nuestro esquema y modelo de mangosta.

25
00:02:12,980 --> 00:02:20,160
Diremos que el usuario enchufe y pasaporte-local-mangosta.

26
00:02:20,160 --> 00:02:23,360
Por lo tanto, esto automáticamente, como dije, agregará soporte para el nombre de

27
00:02:23,360 --> 00:02:28,040
usuario y el almacenamiento hash de la contraseña usando

28
00:02:28,040 --> 00:02:33,305
el hash y la sal y agregará

29
00:02:33,305 --> 00:02:37,235
métodos adicionales en el esquema de usuario

30
00:02:37,235 --> 00:02:40,880
y el modelo que son útiles para la autenticación de pasaporte.

31
00:02:40,880 --> 00:02:48,390
Así que una vez que hayamos completado la actualización del archivo user.js en nuestra carpeta del proyecto,

32
00:02:48,390 --> 00:02:55,160
crearemos un nuevo archivo y lo nombraremos authenticate.js.

33
00:02:55,160 --> 00:02:57,800
En el archivo authentic.js,

34
00:02:57,800 --> 00:03:03,420
permítanme importar pasaporte.

35
00:03:03,940 --> 00:03:10,700
Así que vamos a decir requerir pasaporte y vamos a

36
00:03:10,700 --> 00:03:16,700
utilizar este archivo para almacenar las estrategias de autenticación que vamos a configurar.

37
00:03:16,700 --> 00:03:26,195
Así que diremos var. LocalStrategy requiere passport-local,

38
00:03:26,195 --> 00:03:36,140
por lo que el módulo local de pasaporte exporta una estrategia que podemos usar para nuestra aplicación.

39
00:03:36,140 --> 00:03:39,800
Así que vamos a decir Passport-Local.strategy

40
00:03:39,800 --> 00:03:56,700
y luego vamos a importar usuario de modelos de usuario.

41
00:03:58,550 --> 00:04:06,270
Vamos a configurar ahora el pasaporte con la nueva estrategia local

42
00:04:06,270 --> 00:04:13,970
y luego vamos a exportar esto desde este archivo porque este va a ser un módulo de nodo.

43
00:04:13,970 --> 00:04:23,940
Así que vamos a decir exports.local y vamos a decir pasaporte y

44
00:04:23,940 --> 00:04:28,580
se puede ver que el pasaporte es compatible con los diversos métodos

45
00:04:28,580 --> 00:04:33,710
aquí, así que vamos a decir el uso de pasaporte y decir

46
00:04:33,710 --> 00:04:39,125
nuevo LocalStrategy y entonces aquí es donde

47
00:04:39,125 --> 00:04:47,715
las funciones que son compatibles con el pasaporte-local-mangosta vienen en nuestra ayuda.

48
00:04:47,715 --> 00:04:52,225
Por lo tanto, la estrategia local tendrá que ser suministrada con la función de verificación.

49
00:04:52,225 --> 00:04:55,210
Dentro de esta función verificaremos al usuario.

50
00:04:55,210 --> 00:04:59,090
Esta función de verificación se llamará con el nombre de usuario y la contraseña que el

51
00:04:59,090 --> 00:05:03,380
pasaporte extraerá de nuestra solicitud entrante.

52
00:05:03,380 --> 00:05:09,620
Ahora en la solicitud entrante para LocalStrategy, el nombre de usuario y

53
00:05:09,620 --> 00:05:16,800
la contraseña deben ser proporcionados en el cuerpo del mensaje en forma de una cadena Json.

54
00:05:17,680 --> 00:05:21,560
De nuevo porque estamos haciendo body-parser para que se

55
00:05:21,560 --> 00:05:24,500
agregue al cuerpo del mensaje y luego a partir de ahí el pasaporte

56
00:05:24,500 --> 00:05:29,000
lo recuperaremos y luego lo usaremos y proporcionaremos el nombre de usuario y la contraseña

57
00:05:29,000 --> 00:05:34,775
como parámetros a la función de verificación que proporcionaremos a la LocalStrategy.

58
00:05:34,775 --> 00:05:37,565
Dado que estamos utilizando el plugin de mangosta pasaporte,

59
00:05:37,565 --> 00:05:44,915
el plugin de mangosta en sí agrega esta función llamada user.authenticate.

60
00:05:44,915 --> 00:05:51,495
Por lo tanto, agrega este método al esquema de usuario y al modelo.

61
00:05:51,495 --> 00:05:55,775
Vamos a suministrar eso como la función

62
00:05:55,775 --> 00:06:00,350
que proporcionará la autenticación para LocalStrategy.

63
00:06:00,350 --> 00:06:02,540
Ahora, si no está usando

64
00:06:02,540 --> 00:06:06,875
passport-local-mangoose cuando configura un plugin de mangosta que hemos hecho,

65
00:06:06,875 --> 00:06:08,060
si no está usando eso,

66
00:06:08,060 --> 00:06:12,540
entonces necesita escribir su propia función de autenticación de usuario aquí.

67
00:06:12,540 --> 00:06:15,720
En la conferencia anterior,

68
00:06:15,720 --> 00:06:18,860
le había mostrado una función de autenticación de usuario simple

69
00:06:18,860 --> 00:06:22,580
que se puede utilizar aquí, pero la que es

70
00:06:22,580 --> 00:06:25,610
suministrada por el módulo passport-local-mangosta es más

71
00:06:25,610 --> 00:06:30,200
completa y así que eso es lo que vamos a hacer uso de en nuestra aplicación.

72
00:06:30,200 --> 00:06:36,365
Además, dado que todavía estamos usando sesiones para rastrear usuarios en nuestra aplicación,

73
00:06:36,365 --> 00:06:43,775
necesitamos serializar y deserializar al usuario.

74
00:06:43,775 --> 00:06:47,345
Entonces, esto básicamente toma la información del usuario.

75
00:06:47,345 --> 00:06:54,815
Ahora recuerde que la autenticación de pasaporte montará el req.user o la propiedad del usuario en

76
00:06:54,815 --> 00:06:58,715
el mensaje de solicitud y para

77
00:06:58,715 --> 00:07:04,610
que la información del usuario se serialice y deserialice realizado mediante el uso de

78
00:07:04,610 --> 00:07:17,295
este dicho usuario serializar usuario y pasaporte deserializar usuario.

79
00:07:17,295 --> 00:07:22,235
También diremos usuario deserializar usuario.

80
00:07:22,235 --> 00:07:27,920
Estas dos funciones que serializan usuario y deserializar usuario se proporcionan en

81
00:07:27,920 --> 00:07:35,030
el esquema de usuario y modelo por el uso del plugin passport-local-mangosta aquí.

82
00:07:35,030 --> 00:07:38,240
Así que esto se encargará de todo lo que sea necesario para

83
00:07:38,240 --> 00:07:42,860
nuestro apoyo a las sesiones en pasaporte.

84
00:07:42,860 --> 00:07:48,375
Así que una vez que hayamos completado esta actualización al archivo authenticate.js,

85
00:07:48,375 --> 00:07:54,200
este archivo será necesario donde sea necesario para que lo utilicemos en nuestra autenticación.

86
00:07:54,200 --> 00:07:57,695
A continuación, ir al archivo users.js,

87
00:07:57,695 --> 00:07:59,795
en el archivo users.js,

88
00:07:59,795 --> 00:08:04,170
primero importaremos pasaporte.

89
00:08:04,170 --> 00:08:09,525
Así que vamos a decir var pasaporte requiere pasaporte.

90
00:08:09,525 --> 00:08:16,100
Entonces, debido a que estamos utilizando el plugin de mangosta local pasaporte,

91
00:08:16,100 --> 00:08:20,525
el plugin mangosta en sí proporciona algunas métricas que son

92
00:08:20,525 --> 00:08:25,380
útiles para nosotros para usar en el proceso de registro y en el proceso de inicio de sesión.

93
00:08:25,380 --> 00:08:29,030
Así que bajando a la publicación del enrutador aquí,

94
00:08:29,030 --> 00:08:34,120
el plugin de mangosta nos proporciona un método llamado registro,

95
00:08:34,120 --> 00:08:37,275
en el esquema del usuario y el modelo.

96
00:08:37,275 --> 00:08:44,460
Así que vamos a decir registro de usuario y esto se convertirá en decir nuevo usuario.

97
00:08:44,460 --> 00:08:51,035
Este nuevo usuario es el primer parámetro que toma el registro

98
00:08:51,035 --> 00:08:58,245
y el segundo parámetro es la contraseña del cuerpo req.

99
00:08:58,245 --> 00:09:05,440
Entonces, la contraseña que viene como un segundo parámetro en el cuerpo del mensaje.

100
00:09:05,440 --> 00:09:08,460
Así que recuerde que el nombre de usuario y

101
00:09:08,460 --> 00:09:12,020
la contraseña se pasan cuando se registra en el cuerpo del mensaje.

102
00:09:12,020 --> 00:09:14,255
Ahora, en este caso,

103
00:09:14,255 --> 00:09:19,855
esto dará como resultado una función de devolución de llamada que proporciona un error

104
00:09:19,855 --> 00:09:25,825
y el usuario como los dos valores de devolución de llamada aquí y, lamentablemente

105
00:09:25,825 --> 00:09:28,790
, esto no funciona en este caso.

106
00:09:28,790 --> 00:09:33,045
Así que tendré que cortar esto desde aquí y luego

107
00:09:33,045 --> 00:09:39,415
manejar eso dentro de este método de devolución de llamada aquí.

108
00:09:39,415 --> 00:09:43,820
Entonces, déjame sangrar esto, para

109
00:09:43,820 --> 00:09:48,060
que sea más fácil ver el código aquí.

110
00:09:48,060 --> 00:09:51,830
Así que diré, el usuario se registra y el primer parámetro es

111
00:09:51,830 --> 00:09:53,630
un nuevo usuario creado con

112
00:09:53,630 --> 00:09:57,590
el nombre de usuario de suministro aquí y el segundo parámetro es la contraseña,

113
00:09:57,590 --> 00:10:02,550
y luego el resultado es esta función de devolución de llamada que

114
00:10:02,550 --> 00:10:06,100
llamará, vamos a decir usuario de error aquí.

115
00:10:06,100 --> 00:10:11,260
En este caso, tenemos que editar el código un poco aquí.

116
00:10:11,260 --> 00:10:14,620
Entonces, en la primera parte,

117
00:10:14,620 --> 00:10:21,850
diremos si hay error,

118
00:10:21,850 --> 00:10:28,150
entonces tendrán que devolver explícitamente la respuesta.

119
00:10:28,150 --> 00:10:34,945
Así que, voy a copiar estos dos aquí.

120
00:10:34,945 --> 00:10:37,670
Así que diremos, si el error,

121
00:10:37,740 --> 00:10:40,860
luego res código de estado,

122
00:10:40,860 --> 00:10:46,970
vamos a establecer esto en 500 y establecer el tipo de contenido de encabezado y luego,

123
00:10:46,970 --> 00:10:52,520
vamos a establecer res json y luego error, error.

124
00:10:52,520 --> 00:10:56,790
Por lo tanto, construiremos un objeto json con el error como

125
00:10:56,790 --> 00:11:01,590
el valor de la propiedad de error allí y luego enviaremos esto de vuelta.

126
00:11:01,590 --> 00:11:06,145
Entonces, así es como manejarías el error en este caso.

127
00:11:06,145 --> 00:11:11,110
De lo contrario, lo que hacemos aquí es que

128
00:11:11,110 --> 00:11:18,970
diremos pasaporte autenticar local.

129
00:11:18,970 --> 00:11:23,810
Así que si vamos a utilizar el pasaporte para autenticar al usuario de nuevo.

130
00:11:23,810 --> 00:11:25,930
Así que diremos que el pasaporte autentica local.

131
00:11:25,930 --> 00:11:28,820
Para asegurarse de que el registro de usuario se realizó correctamente.

132
00:11:28,820 --> 00:11:33,145
intentaremos autenticar al mismo usuario que acabamos de registrar y

133
00:11:33,145 --> 00:11:38,335
aquí diremos req res y esto

134
00:11:38,335 --> 00:11:48,355
devolverá como un tercer valor esa función dentro del cual,

135
00:11:48,355 --> 00:11:52,300
vamos a devolver la respuesta a nuestro cliente.

136
00:11:52,300 --> 00:12:01,140
Así que diremos. Déjame eliminar esto y luego agregarlo aquí.

137
00:12:01,140 --> 00:12:03,190
Ahora podemos eliminar esto entonces,

138
00:12:03,190 --> 00:12:11,070
porque esto entonces no es necesario para nosotros y este es el cierre del registro de usuarios.

139
00:12:11,070 --> 00:12:12,990
En la otra parte,

140
00:12:12,990 --> 00:12:16,810
vamos a hacer pasaporte autenticar local.

141
00:12:16,970 --> 00:12:19,510
Mira la sintaxis aquí.

142
00:12:19,510 --> 00:12:23,425
Así que este es el pasaporte autenticar local y luego, después de eso,

143
00:12:23,425 --> 00:12:29,325
tenemos que llamar a esta función aquí que los parámetros req,

144
00:12:29,325 --> 00:12:35,245
res y que el tercero es una función de devolución de llamada aquí.

145
00:12:35,245 --> 00:12:42,275
Así que esta es la forma en que esto se implementa porque pasaporte espera que lo hagas de esta manera.

146
00:12:42,275 --> 00:12:46,495
Aquí, estableceremos el código de estado req res es 200,

147
00:12:46,495 --> 00:12:49,930
estableceremos la aplicación de contenido de encabezado json y luego nos

148
00:12:49,930 --> 00:12:59,410
res registro de estado json exitoso y no pasaremos el valor de usuario aquí.

149
00:12:59,410 --> 00:13:03,240
En cambio, lo que voy a hacer es

150
00:13:03,240 --> 00:13:10,695
establecer una bandera llamada éxito aquí a verdadero aquí.

151
00:13:10,695 --> 00:13:15,620
Ahora de esta manera, en nuestro lado cliente cuando se recibe este json,

152
00:13:15,620 --> 00:13:20,550
el cliente simplemente puede extraer la propiedad de éxito y luego verificar si es cierto

153
00:13:20,550 --> 00:13:25,695
o no para verificar rápidamente si el registro fue exitoso o no.

154
00:13:25,695 --> 00:13:32,000
Así es como manejaremos el proceso de registro de usuarios aquí.

155
00:13:32,000 --> 00:13:35,470
Así que observe cómo el código se ha simplificado significativamente.

156
00:13:35,470 --> 00:13:38,924
Si el usuario no se registró correctamente,

157
00:13:38,924 --> 00:13:45,665
entonces esto devolverá un error apropiadamente y también la autenticación fallará.

158
00:13:45,665 --> 00:13:51,115
Por lo tanto, en ambos casos, detectará la situación cuando falla la autenticación del usuario.

159
00:13:51,115 --> 00:13:56,270
Ahora, el proceso de inicio de sesión en sí también se simplifica significativamente.

160
00:13:56,270 --> 00:14:01,650
Por lo tanto, no necesitamos hacer todo esto en la ruta de inicio de sesión aquí.

161
00:14:01,650 --> 00:14:07,220
Así que voy a eliminar todo este código y esta ruta de inicio de sesión se simplifica aquí.

162
00:14:07,220 --> 00:14:14,365
Ahora, para la ruta de inicio de sesión- para la publicación del enrutador cuando lo hacemos

163
00:14:14,365 --> 00:14:19,150
aquí, aquí también esperamos que el nombre de usuario y la contraseña se incluyan

164
00:14:19,150 --> 00:14:24,240
en el cuerpo del mensaje de publicación que viene ella.

165
00:14:24,240 --> 00:14:32,030
A diferencia del caso anterior en el que estábamos incluyendo esto en el encabezado de autorización,

166
00:14:32,030 --> 00:14:37,865
aquí esperamos que esto se incluya en el cuerpo del mensaje de entrada.

167
00:14:37,865 --> 00:14:47,730
Así que para autenticar, simplemente diremos autentificar pasaporte y diremos local aquí.

168
00:14:47,730 --> 00:14:52,320
Así que esta será la segunda llamada aquí.

169
00:14:52,320 --> 00:14:55,360
Así que este es el segundo middleware que vamos a cortar.

170
00:14:55,360 --> 00:15:01,690
Por lo tanto, cuando la publicación del enrutador entra en el extremo de inicio de sesión,

171
00:15:01,690 --> 00:15:06,095
primero llamaremos al pasaporte autenticar local.

172
00:15:06,095 --> 00:15:09,660
Si esto es exitoso entonces esto entrará

173
00:15:09,660 --> 00:15:13,485
y se ejecutará la siguiente función que sigue.

174
00:15:13,485 --> 00:15:15,760
Si hay algún error en la autenticación,

175
00:15:15,760 --> 00:15:18,850
este pasaporte autenticar local

176
00:15:18,850 --> 00:15:24,210
enviará automáticamente una respuesta al cliente sobre el error de la autenticación.

177
00:15:24,210 --> 00:15:26,190
Así que eso ya está atendido.

178
00:15:26,190 --> 00:15:33,345
Así que observe cómo el código en el proceso de inicio de sesión se simplifica significativamente.

179
00:15:33,345 --> 00:15:36,565
Entonces, si esto se realiza con éxito,

180
00:15:36,565 --> 00:15:42,775
solo necesito verificar el req y res y aquí lo que

181
00:15:42,775 --> 00:15:49,665
haré es simplemente enviaré un mensaje al lado del cliente con esta información aquí.

182
00:15:49,665 --> 00:15:53,775
Vamos a decir que el código de estado de res 200,

183
00:15:53,775 --> 00:16:02,145
res establecer el tipo de contenido de encabezado de la aplicación json y res json status verdadero éxito.

184
00:16:02,145 --> 00:16:13,010
Vamos a decir, que ha iniciado sesión con éxito.

185
00:16:13,010 --> 00:16:18,100
Eso es todo. Este es el cambio que vamos a hacer en el archivo users.js.

186
00:16:18,100 --> 00:16:21,275
Así que observe cómo, debido al pasaporte de usuario,

187
00:16:21,275 --> 00:16:24,655
tanto el proceso de registro como el proceso de inicio de sesión,

188
00:16:24,655 --> 00:16:28,205
el código se ha simplificado significativamente en este caso.

189
00:16:28,205 --> 00:16:34,465
Ahora pasaremos a actualizar el archivo app.js yendo a app.js ahora.

190
00:16:34,465 --> 00:16:37,555
En app.js justo aquí,

191
00:16:37,555 --> 00:16:50,540
ingresaremos pasaporte.

192
00:16:51,270 --> 00:16:55,310
Luego, importaremos

193
00:16:59,820 --> 00:17:07,120
el módulo de autenticación que acabamos de implementar.

194
00:17:07,120 --> 00:17:15,390
Diremos var authenticate y en el archivo app.js abajo aquí después de la sesión,

195
00:17:15,390 --> 00:17:25,320
agregamos app.use (passport.initialize)

196
00:17:25,320 --> 00:17:32,100
y app.use (.session).

197
00:17:32,950 --> 00:17:37,810
Si el usuario ha iniciado sesión,

198
00:17:37,810 --> 00:17:42,945
entonces lo que sucede es que cuando se inicia la sesión de nuevo,

199
00:17:42,945 --> 00:17:47,095
recuerda que cuando inicia sesión aquí,

200
00:17:47,095 --> 00:17:48,735
va a iniciar sesión aquí,

201
00:17:48,735 --> 00:17:51,705
y una llamada al pasaporte autenticar local,

202
00:17:51,705 --> 00:17:53,730
cuando esto se hace en la etapa de inicio de sesión,

203
00:17:53,730 --> 00:17:56,460
el pasaporte autenticar local se

204
00:17:56,460 --> 00:18:00,625
agregue automáticamente la propiedad de usuario al mensaje de solicitud.

205
00:18:00,625 --> 00:18:03,415
Por lo tanto, agregará req.user y, a continuación,

206
00:18:03,415 --> 00:18:07,265
la sesión de pasaporte que hemos hecho aquí

207
00:18:07,265 --> 00:18:12,575
serializará automáticamente esa información del usuario y luego la almacenará en la sesión.

208
00:18:12,575 --> 00:18:15,925
Por lo tanto, y posteriormente, cada vez que

209
00:18:15,925 --> 00:18:19,135
una solicitud entrante entra desde el lado del cliente

210
00:18:19,135 --> 00:18:22,630
con la cookie de sesión ya en su lugar,

211
00:18:22,630 --> 00:18:29,250
esto cargará automáticamente el req.user en la solicitud entrante.

212
00:18:29,250 --> 00:18:32,735
Entonces, así es como se organiza la sesión de pasaporte en sí.

213
00:18:32,735 --> 00:18:34,445
Entonces, una vez hecho esto,

214
00:18:34,445 --> 00:18:40,075
incluso nuestro código de autenticación será mucho más simple aquí.

215
00:18:40,075 --> 00:18:42,400
Entonces, en el código de autenticación,

216
00:18:42,400 --> 00:18:49,450
simplemente diremos, si req.user.

217
00:18:49,450 --> 00:18:55,690
Por lo tanto, el middleware de la sesión de pasaporte cargará el req.user automáticamente, por

218
00:18:55,690 --> 00:18:58,845
lo que diremos req.user.

219
00:18:58,845 --> 00:19:03,940
Si no req.user diremos var err, nuevo

220
00:19:03,940 --> 00:19:09,495
error, no está autenticado, y todos estos mensajes aquí.

221
00:19:09,495 --> 00:19:15,410
De lo contrario, ver la parte de lo demás también ahora se simplifica.

222
00:19:17,280 --> 00:19:20,010
Vamos a decir lo siguiente.

223
00:19:20,010 --> 00:19:27,335
Por lo tanto, su código de autenticación se vuelve mucho más simple porque si req.user no está presente,

224
00:19:27,335 --> 00:19:31,695
entonces eso significa que la autenticación no se ha hecho correctamente,

225
00:19:31,695 --> 00:19:33,345
por eso indica el error.

226
00:19:33,345 --> 00:19:35,470
De lo contrario, se autenticará.

227
00:19:35,470 --> 00:19:37,110
Si req.user está presente,

228
00:19:37,110 --> 00:19:39,900
significa que el pasaporte ha realizado la autenticación y el

229
00:19:39,900 --> 00:19:42,970
usuario req.user se carga en el mensaje de solicitud,

230
00:19:42,970 --> 00:19:46,410
por lo que puede ir más abajo.

231
00:19:46,410 --> 00:19:49,815
Entonces, ese es el cambio que tenemos que hacer a app.js.

232
00:19:49,815 --> 00:19:57,775
Vamos a guardar todos los cambios y luego mirar la aplicación en Postman.

233
00:19:57,775 --> 00:20:01,385
Una vez que guarde todos los cambios, reinicie el servidor.

234
00:20:01,385 --> 00:20:02,600
Si el servidor se está ejecutando,

235
00:20:02,600 --> 00:20:04,700
deténgalo y, a continuación, reinicie el servidor.

236
00:20:04,700 --> 00:20:07,680
Déjame iniciar mi servidor.

237
00:20:08,160 --> 00:20:10,450
Una vez que el servidor esté en funcionamiento,

238
00:20:10,450 --> 00:20:13,900
vayamos a Postman y hagamos algunas peticiones.

239
00:20:13,900 --> 00:20:17,650
Ir a Postman, permítanme ahora tratar de registrar un nuevo usuario

240
00:20:17,650 --> 00:20:22,120
haciendo una publicación en el punto final de registro de los usuarios.

241
00:20:22,120 --> 00:20:28,485
Cuando se registra el registro,

242
00:20:28,485 --> 00:20:31,850
verá que en el cuerpo del mensaje de respuesta dice,

243
00:20:31,850 --> 00:20:35,805
éxito verdadero y estado de registro exitoso.

244
00:20:35,805 --> 00:20:40,430
Por lo tanto, el usuario se ha registrado correctamente en el lado del cliente.

245
00:20:40,430 --> 00:20:44,870
Entonces, ahora, déjame hacer un inicio de sesión del usuario.

246
00:20:44,870 --> 00:20:50,000
Entonces, diremos, «Iniciar sesión», y aún así proporcionaremos

247
00:20:50,000 --> 00:20:55,765
el nombre de usuario y la contraseña en el cuerpo del mensaje aquí.

248
00:20:55,765 --> 00:20:58,345
Por lo tanto, cuando haga clic en «Enviar»,

249
00:20:58,345 --> 00:21:02,550
inmediatamente notará que en la parte inferior

250
00:21:02,550 --> 00:21:05,050
, dice, éxito, verdadero y estado,

251
00:21:05,050 --> 00:21:09,440
está conectado y luego en el encabezado mismo,

252
00:21:09,440 --> 00:21:13,515
verá una cookie de conjunto entrando porque estamos configurando la sesión,

253
00:21:13,515 --> 00:21:17,390
y luego verá la cookie en su lugar allí.

254
00:21:17,390 --> 00:21:19,465
Al hacer clic en las cookies,

255
00:21:19,465 --> 00:21:23,875
verá el ID de sesión en su lugar justo allí.

256
00:21:23,875 --> 00:21:26,980
Por lo tanto, ahora hemos iniciado sesión con éxito.

257
00:21:26,980 --> 00:21:35,630
Vamos a enviar una solicitud al punto final Get localhost: 3000 platos.

258
00:21:35,630 --> 00:21:42,210
Ves que tu solicitud se ha enviado correctamente y, a continuación, se ha enviado una respuesta.

259
00:21:42,210 --> 00:21:43,350
Por supuesto, en este momento,

260
00:21:43,350 --> 00:21:48,330
mi base de datos está vacía, por lo que envía una matriz vacía

261
00:21:48,330 --> 00:21:54,530
desde el sitio del servidor cuando pido localhost: 3000/platos.

262
00:21:55,050 --> 00:21:58,165
Esto está perfectamente bien.

263
00:21:58,165 --> 00:22:00,610
Permítanme ahora cerrar la sesión del usuario.

264
00:22:00,610 --> 00:22:02,995
Por lo tanto, cuando cierre la sesión del usuario, ahora,

265
00:22:02,995 --> 00:22:10,450
notará que el usuario ha sido desconectado y cuando haga clic en las cookies,

266
00:22:10,450 --> 00:22:14,660
notará que, esa cookie para localhost ya se ha ido.

267
00:22:14,660 --> 00:22:19,245
Entonces, ahora, si intentas hacer un get en el localhost: platos,

268
00:22:19,245 --> 00:22:24,910
ves que la respuesta dice,

269
00:22:24,910 --> 00:22:26,640
no estás autenticado.

270
00:22:26,640 --> 00:22:32,760
Vamos a iniciar sesión una vez más haciendo una publicación en el inicio de sesión de los usuarios,

271
00:22:32,760 --> 00:22:36,290
y luego, verá que podemos iniciar sesión con éxito en este punto.

272
00:22:36,290 --> 00:22:37,830
También nota que,

273
00:22:37,830 --> 00:22:40,075
esa nueva cookie se ha configurado aquí.

274
00:22:40,075 --> 00:22:44,480
Entonces, si hacemos un get en el localhost:platos aquí,

275
00:22:44,480 --> 00:22:46,465
ahora, esto será exitoso.

276
00:22:46,465 --> 00:22:51,624
Dado que estamos utilizando la mangosta local de pasaporte como el plugin de mangosta,

277
00:22:51,624 --> 00:22:55,790
vamos también a revisar nuestro servidor MongoDB para ver cómo

278
00:22:55,790 --> 00:23:00,410
la información del usuario se almacena realmente en nuestro MongoDB.

279
00:23:00,410 --> 00:23:04,880
Por lo tanto, en su terminal,

280
00:23:04,880 --> 00:23:06,970
puede abrir la ondulación Mongo,

281
00:23:06,970 --> 00:23:11,775
así que digamos Mongo en la terminal y luego conectarse a nuestro servidor MongoDB,

282
00:23:11,775 --> 00:23:16,500
y luego decir use ConFusion.

283
00:23:16,500 --> 00:23:26,285
Luego diremos db.users.find () .pretty () y luego imprimiremos la información del usuario.

284
00:23:26,285 --> 00:23:31,180
Por lo tanto, cuando imprime la información del usuario como ve aquí,

285
00:23:31,180 --> 00:23:35,235
hay un usuario que nos hemos registrado anteriormente.

286
00:23:35,235 --> 00:23:40,840
Por lo tanto, verá que el registro del usuario contiene el ID del objeto y luego,

287
00:23:40,840 --> 00:23:42,665
el nombre de usuario abajo aquí,

288
00:23:42,665 --> 00:23:46,060
y el indicador de administrador que es falso y luego,

289
00:23:46,060 --> 00:23:53,720
también notará que en lugar de almacenar la contraseña en sí lo que

290
00:23:53,720 --> 00:23:57,515
hace el plugin mangosta local de pasaportes de Mongos es almacenar

291
00:23:57,515 --> 00:24:01,865
su valor de sal aquí y un valor hash aquí.

292
00:24:01,865 --> 00:24:08,655
Ahora, lo que hace el plugin de Mongo es que usará la sal como una forma de

293
00:24:08,655 --> 00:24:15,990
cifrar la contraseña e instalar la contraseña hash en este campo hash aquí.

294
00:24:15,990 --> 00:24:17,980
Por lo tanto, cuando intente iniciar sesión,

295
00:24:17,980 --> 00:24:23,130
aplicará la misma transformación a la contraseña entrante

296
00:24:23,130 --> 00:24:27,330
y luego intentará hacer coincidir con este valor hash que se almacena aquí.

297
00:24:27,330 --> 00:24:29,580
Por lo tanto, puede ver que en la base de datos en sí,

298
00:24:29,580 --> 00:24:32,855
la contraseña no se almacena directamente dentro

299
00:24:32,855 --> 00:24:38,280
del valor hash de la contraseña que se hash usando esta clave sal aquí,

300
00:24:38,280 --> 00:24:39,435
que vemos aquí,

301
00:24:39,435 --> 00:24:42,780
se almacena en el registro allí.

302
00:24:42,780 --> 00:24:47,440
Así, así es como el plugin mangosta local del pasaporte nos permite

303
00:24:47,440 --> 00:24:53,905
almacenar la información del usuario dentro de nuestra base de datos.

304
00:24:53,905 --> 00:24:58,680
Con esta rápida comprensión de cómo pasaporte, pasaporte-local

305
00:24:58,680 --> 00:25:02,590
y Passport-Local-Mangoose nos ayudan a simplificar

306
00:25:02,590 --> 00:25:09,390
la estrategia local de nombre de usuario y contraseña en nuestra aplicación.

307
00:25:09,390 --> 00:25:11,660
Completamos este ejercicio.

308
00:25:11,660 --> 00:25:18,390
Este es un buen momento para que hagas un compromiso de Git con el pasaporte de mensaje.