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

2
00:00:04,470 --> 00:00:10,326
El servidor Express REST API que implementamos en el

3
00:00:10,326 --> 00:00:17,750
módulo anterior permite a cualquier usuario realizar cualquiera de las operaciones GET, POST o DELETE.

4
00:00:17,750 --> 00:00:21,360
No hay control sobre quién puede realizar esta operación.

5
00:00:21,360 --> 00:00:22,350
Lo que significa que,

6
00:00:22,350 --> 00:00:27,180
si ejecuta un servidor como ese, entonces cualquiera puede entrar en su servidor y

7
00:00:27,180 --> 00:00:33,420
comenzar a manipular la información que está presente dentro de su base de datos.

8
00:00:33,420 --> 00:00:36,578
Obviamente, esta es una situación peligrosa.

9
00:00:36,578 --> 00:00:40,380
La forma en que debe implementarse el servidor es que,

10
00:00:40,380 --> 00:00:44,330
necesita tener algún tipo de restricción sobre

11
00:00:44,330 --> 00:00:48,660
qué tipos de usuarios podrán realizar qué tipos de operaciones.

12
00:00:48,660 --> 00:00:51,090
Así que tal vez, permitiría y

13
00:00:51,090 --> 00:00:54,650
un usuario autorizado solo realizar operaciones GET.

14
00:00:54,650 --> 00:01:00,040
Así, por ejemplo, si quieres que un invitado pueda ver información

15
00:01:00,040 --> 00:01:04,860
sobre los platos en tu restaurante o el menú de tu restaurante,

16
00:01:04,860 --> 00:01:07,250
etc., eso es perfectamente aceptable.

17
00:01:07,250 --> 00:01:11,699
Pero, puede permitir que solo un administrador ingrese y

18
00:01:11,699 --> 00:01:17,780
modifique la información sobre el plato o elimine un plato del menú.

19
00:01:17,780 --> 00:01:23,448
Y también actualice un plato existente en el menú, o una promoción,

20
00:01:23,448 --> 00:01:29,062
o la información sobre los líderes en su lado del servidor.

21
00:01:29,062 --> 00:01:34,810
Ahora, también podría tener otro grupo de usuarios que serán usuarios registrados

22
00:01:34,810 --> 00:01:39,980
que pueden tener permiso para guardar algunos de sus platos como sus platos favoritos,

23
00:01:39,980 --> 00:01:44,290
y sólo ellos serían capaces de manipular la lista de sus platos favoritos.

24
00:01:44,290 --> 00:01:47,850
Así que ese es otro nivel de autorización o

25
00:01:47,850 --> 00:01:49,940
autenticación que necesita realizar.

26
00:01:49,940 --> 00:01:53,400
Por lo tanto, tiene diferentes grados de usuarios, y

27
00:01:53,400 --> 00:01:57,820
también, dependiendo del tipo de operaciones que se les permitiría realizar.

28
00:01:57,820 --> 00:02:01,880
Así que todo esto significa que necesita algún tipo de seguridad para ser

29
00:02:01,880 --> 00:02:03,840
incorporado en su lado del servidor.

30
00:02:03,840 --> 00:02:07,970
Vamos a ver cómo podemos autenticar a los usuarios y

31
00:02:07,970 --> 00:02:13,110
luego decidir qué tipo de usuario es este cliente.

32
00:02:13,110 --> 00:02:15,410
Y luego, dependiendo del tipo de usuario,

33
00:02:15,410 --> 00:02:19,360
puede permitir que el usuario realice ciertos tipos de operaciones.

34
00:02:19,360 --> 00:02:24,630
Comenzaremos con la comprensión básica de esto, lo que llamamos como

35
00:02:24,630 --> 00:02:30,860
Autenticación Básica en un lado del servidor para

36
00:02:30,860 --> 00:02:36,940
un cliente, y luego, construiremos sobre eso a lo largo del resto de este módulo.

37
00:02:36,940 --> 00:02:42,030
Y luego, al final de este módulo, terminaremos con un mecanismo

38
00:02:42,030 --> 00:02:46,170
, lo que permitirá a los usuarios registrarse.

39
00:02:46,170 --> 00:02:50,220
Además, los usuarios registrados pueden realizar ciertas operaciones

40
00:02:50,220 --> 00:02:53,930
que un usuario no registrado no puede, y así sucesivamente.

41
00:02:53,930 --> 00:02:57,320
Así que vamos a imponer varios tipos de controles de acceso para

42
00:02:57,320 --> 00:03:01,990
varias operaciones en el lado del servidor en función del tipo de usuario.

43
00:03:01,990 --> 00:03:04,930
Así que eso te establece la perspectiva, o

44
00:03:04,930 --> 00:03:09,830
más bien la idea de lo que encontrarás en este módulo.

45
00:03:09,830 --> 00:03:12,450
Comencemos con la autenticación básica,

46
00:03:12,450 --> 00:03:18,450
el mecanismo básico que nos permitirá autenticar a los usuarios. La

47
00:03:19,970 --> 00:03:25,173
autenticación básica en HTTP es un mecanismo muy simple,

48
00:03:25,173 --> 00:03:28,782
que pedirá al usuario un nombre de usuario y

49
00:03:28,782 --> 00:03:32,720
contraseña para ser enviado con una solicitud.

50
00:03:32,720 --> 00:03:35,180
Y hay una estructura específica

51
00:03:35,180 --> 00:03:39,920
sobre cómo se enviará esta información desde el cliente al lado del servidor.

52
00:03:39,920 --> 00:03:45,060
Por lo tanto, esta es una cuestión, la autenticación de acceso básica, que admite HTTP,

53
00:03:45,060 --> 00:03:49,860
es una cuestión que permitirá a un servidor desafiar a un cliente, y pedir

54
00:03:49,860 --> 00:03:53,110
el nombre de usuario y la contraseña para ser enviado por el cliente.

55
00:03:53,110 --> 00:03:57,714
Por lo tanto, el servidor puede desafiar al cliente a autenticarse escribiendo esta

56
00:03:57,714 --> 00:03:59,140
información.

57
00:03:59,140 --> 00:04:01,880
El cliente necesita enviar el nombre de usuario y la

58
00:04:01,880 --> 00:04:05,440
contraseña en respuesta al desafío desde el lado del servidor.

59
00:04:05,440 --> 00:04:09,870
Por lo tanto, cada mensaje de solicitud que se origina desde un cliente

60
00:04:09,870 --> 00:04:13,870
debe incluir la forma codificada del nombre de usuario y

61
00:04:13,870 --> 00:04:19,700
la contraseña en el encabezado de solicitud que va del cliente al lado del servidor.

62
00:04:19,700 --> 00:04:22,229
Por lo tanto, cuando el servidor recibe

63
00:04:22,229 --> 00:04:27,009
la solicitud, el servidor extraerá esta información del encabezado de solicitud del cliente.

64
00:04:27,009 --> 00:04:31,831
Y luego, use eso para autenticar el cliente antes de

65
00:04:31,831 --> 00:04:37,390
permitir el acceso a las diversas operaciones en el lado del servidor.

66
00:04:37,390 --> 00:04:40,850
Entonces, ¿cómo funciona esta autenticación?

67
00:04:40,850 --> 00:04:44,450
Si un cliente envía una solicitud al servidor, y

68
00:04:44,450 --> 00:04:50,150
esta solicitud de cliente no incluye la formación de autorización, entonces el servidor

69
00:04:50,150 --> 00:04:55,160
desafiará al cliente, está pidiendo al cliente que envíe esta información.

70
00:04:55,160 --> 00:04:58,100
El servidor desafía al cliente mediante la inclusión de

71
00:04:58,100 --> 00:05:01,900
un encabezado en el mensaje de respuesta entrante.

72
00:05:01,900 --> 00:05:06,410
El encabezado con el tipo como WWW-Authenticate, y

73
00:05:06,410 --> 00:05:11,843
luego la segunda parte donde especifica el tipo es donde

74
00:05:11,843 --> 00:05:17,500
especificará qué tipo de autenticación debe enviar el cliente.

75
00:05:17,500 --> 00:05:21,990
Y comenzaremos con la comprensión de la autenticación básica aquí.

76
00:05:21,990 --> 00:05:26,400
Y también observe que el mensaje de respuesta contendrá un código de error 401,

77
00:05:27,570 --> 00:05:31,270
que no es autorizado, que significa no autorizado.

78
00:05:31,270 --> 00:05:35,470
Entonces, cuando la respuesta regresa desde el lado del servidor, entonces el cliente,

79
00:05:35,470 --> 00:05:41,300
en respuesta a esta respuesta entrando, el cliente tendrá que enviar su solicitud,

80
00:05:41,300 --> 00:05:49,550
incluyendo un campo de encabezado específico en el mensaje de solicitud de la autorización de tipo.

81
00:05:49,550 --> 00:05:55,250
Y este campo de encabezado de autorización contendrá cierta información allí.

82
00:05:55,250 --> 00:06:00,440
Para una autenticación básica, esta información sería en la forma de,

83
00:06:00,440 --> 00:06:03,900
como la primera palabra aquí, será Básico.

84
00:06:03,900 --> 00:06:11,410
Y luego seguido de un espacio aquí, y seguido de una cadena codificada Base64 aquí.

85
00:06:11,410 --> 00:06:15,358
Esta cadena codificada en Base64 codifica el nombre de usuario y la

86
00:06:15,358 --> 00:06:21,350
contraseña en un formato particular, y luego lo incluye en el encabezado.

87
00:06:21,350 --> 00:06:25,479
Ahora estás diciendo, si envías un mensaje de solicitud como este,

88
00:06:25,479 --> 00:06:29,397
incluyendo este, en el encabezado, entonces cualquiera en el medio.

89
00:06:29,397 --> 00:06:33,538
Así que si usted sabe algo acerca de la seguridad y

90
00:06:33,538 --> 00:06:39,927
cómo el hombre en el medio ataque puede ser lanzado, entonces obviamente,

91
00:06:39,927 --> 00:06:44,777
esto puede ser recuperado por un intruso en el medio,

92
00:06:44,777 --> 00:06:49,590
y luego puede ser usado para falsificar al cliente real.

93
00:06:49,590 --> 00:06:52,720
Una vez más, no estamos entrando en esa cuestión en este momento.

94
00:06:52,720 --> 00:06:57,470
Cuando hablo de HTTPS en el siguiente módulo,

95
00:06:57,470 --> 00:07:00,880
volveré para abordar ese problema con un poco más de detalle.

96
00:07:00,880 --> 00:07:06,060
Pero por el momento, la información en el encabezado será enviada

97
00:07:07,880 --> 00:07:11,930
sin ser encriptada en el encabezado en este momento.

98
00:07:11,930 --> 00:07:15,460
Ahora, otra razón por la que estoy haciendo esto es que, para que podamos realmente mirar

99
00:07:15,460 --> 00:07:20,150
el encabezado directamente y luego ver esta información en el encabezado mismo.

100
00:07:20,150 --> 00:07:25,401
Por lo tanto, cuando el cliente envía esta solicitud, el servidor extraerá

101
00:07:25,401 --> 00:07:30,930
la información de este encabezado de autorización en el encabezado de solicitud.

102
00:07:30,930 --> 00:07:35,078
Y luego use esta información para verificar si se trata de

103
00:07:35,078 --> 00:07:37,670
una solicitud de cliente autorizada o no.

104
00:07:37,670 --> 00:07:40,412
Ahora, por supuesto, su siguiente pregunta sería,

105
00:07:40,412 --> 00:07:44,490
¿qué contiene exactamente este encabezado de autorización?

106
00:07:44,490 --> 00:07:48,350
El encabezado de autorización en sí se construye de la siguiente manera.

107
00:07:48,350 --> 00:07:52,180
Si tiene un nombre de usuario y una contraseña, estos son los dos

108
00:07:52,180 --> 00:07:55,730
elementos de información que utilizará para autenticar un cliente.

109
00:07:55,730 --> 00:08:01,330
Por lo tanto, el nombre de usuario y la contraseña se concatenarán en una

110
00:08:01,330 --> 00:08:06,910
sola cadena diciendo nombre de usuario y dos puntos, y la contraseña misma.

111
00:08:06,910 --> 00:08:09,860
Entonces la cadena de nombre de usuario, dos puntos y

112
00:08:09,860 --> 00:08:16,210
contraseña se concatenarán juntos en una cadena completa aquí.

113
00:08:16,210 --> 00:08:22,994
Esta cadena resultante que obtenemos aquí es esa, codificada usando codificación Base64.

114
00:08:22,994 --> 00:08:27,344
Si sabe acerca de cómo se realiza la codificación conceptos básicos para la codificación,

115
00:08:27,344 --> 00:08:32,390
conviértalo en un encabezado ASCII como se muestra en este ejemplo aquí, por

116
00:08:32,390 --> 00:08:36,195
lo que esto no es más que una cadena de encabezados ASCII.

117
00:08:36,195 --> 00:08:39,545
Ahora, si no sabe mucho sobre la codificación rígida básica, no se preocupe por

118
00:08:39,545 --> 00:08:44,325
ello, no afecta su comprensión de lo que está pasando aquí de todos modos.

119
00:08:44,325 --> 00:08:47,090
Entonces, este Basic64 codificó cadenas, por lo que

120
00:08:47,090 --> 00:08:51,950
esta información en particular se codifica en una cadena como esta, y

121
00:08:51,950 --> 00:08:57,090
luego se enmarca en el encabezado de solicitud que va del cliente al servidor.

122
00:08:57,090 --> 00:09:02,143
El encabezado de solicitud en sí es de la autorización de tipo,

123
00:09:02,143 --> 00:09:07,194
y luego seguido por el valor real aquí, que dice,

124
00:09:07,194 --> 00:09:13,774
Basic, y un espacio aquí, y la cadena codificada Base64 aquí.

125
00:09:13,774 --> 00:09:20,034
Por lo tanto, cuando esto sea recibido por nuestro servidor, el servidor extraerá esta información,

126
00:09:20,034 --> 00:09:25,059
y luego de aquí, extraerá el nombre de usuario y la contraseña, y

127
00:09:25,059 --> 00:09:31,620
luego verificará si coincide con un usuario autorizado o no en el lado del servidor.

128
00:09:31,620 --> 00:09:36,917
Para ayudarle a entender mejor cómo organizamos realmente la aplicación express

129
00:09:36,917 --> 00:09:42,211
y cómo se lleva a cabo la autenticación en sí, como hemos aprendido anteriormente,

130
00:09:42,211 --> 00:09:47,520
las aplicaciones express se organizan en un conjunto de middleware.

131
00:09:47,520 --> 00:09:51,690
Y la forma en que funciona la aplicación express es que el middleware

132
00:09:51,690 --> 00:09:55,630
se aplica a la solicitud y al mensaje de respuesta

133
00:09:55,630 --> 00:10:00,940
en el orden en que se declara en mi aplicación expresa.

134
00:10:00,940 --> 00:10:05,290
Entonces, si tiene un express.use y

135
00:10:05,290 --> 00:10:09,740
luego tiene el primero que dice un servidor estático, luego de eso,

136
00:10:09,740 --> 00:10:13,220
tiene otro middleware, luego de eso, tiene otro middleware.

137
00:10:13,220 --> 00:10:18,560
La secuencia en la que se declaran en el archivo app.js de servidores rápidos,

138
00:10:18,560 --> 00:10:23,600
por ejemplo, es la secuencia exacta en la que se aplicará el middleware.

139
00:10:23,600 --> 00:10:29,124
Entonces, una solicitud entrante desde el lado del servidor como recuerda en su

140
00:10:29,124 --> 00:10:34,690
aplicación expresa, la solicitud entrante se trata como un objeto de solicitud.

141
00:10:34,690 --> 00:10:39,050
El objeto de respuesta es lo que construye

142
00:10:39,050 --> 00:10:43,310
el servidor express, y luego el siguiente le permite pasar al siguiente middleware

143
00:10:43,310 --> 00:10:45,910
que va a aplicar, y así sucesivamente.

144
00:10:45,910 --> 00:10:52,400
Entonces, una solicitud entrante como esta, cuando entra, se aplica el primer middleware.

145
00:10:52,400 --> 00:10:56,164
Y luego, una vez que ese middleware ha transformado tanto

146
00:10:56,164 --> 00:11:00,680
la solicitud como la respuesta, pasa al siguiente middleware, que luego se aplica a él.

147
00:11:00,680 --> 00:11:03,940
Así, por ejemplo, vimos que aplicamos Morgan primero,

148
00:11:03,940 --> 00:11:06,930
luego aplicamos el analizador corporal al middleware.

149
00:11:06,930 --> 00:11:12,930
Por lo tanto, ya deben haber transformado la solicitud y los objetos de respuesta.

150
00:11:12,930 --> 00:11:17,440
Y luego, después de eso, podemos incluir un middleware de autenticación en su lugar.

151
00:11:17,440 --> 00:11:22,260
El middleware de autenticación va a autenticar la solicitud.

152
00:11:22,260 --> 00:11:26,950
Ahora, por lo que si está utilizando la autenticación básica, haga su solicitud

153
00:11:26,950 --> 00:11:31,970
debe contener en el encabezado el encabezado de autorización en su lugar allí.

154
00:11:31,970 --> 00:11:36,260
Por lo tanto, el middleware de autenticación extraerá el encabezado de autorización

155
00:11:36,260 --> 00:11:40,180
y luego se comprobará para ver si el usuario está autorizado.

156
00:11:40,180 --> 00:11:46,099
Y si el middleware de autenticación detecta que usted es un usuario autorizado,

157
00:11:46,099 --> 00:11:50,515
se le permitirá continuar con el siguiente conjunto de

158
00:11:50,515 --> 00:11:54,427
middleware que sigue el paso de autenticación.

159
00:11:54,427 --> 00:11:58,510
Y sus registros serán procesados por el middleware posterior.

160
00:11:58,510 --> 00:11:59,519
Pero por otro lado,

161
00:11:59,519 --> 00:12:04,422
si su middleware de autenticación decide que no es un usuario autorizado,

162
00:12:04,422 --> 00:12:09,197
entonces el middleware de autenticación lo llevará a lo largo de una ruta diferente.

163
00:12:09,197 --> 00:12:13,975
Y luego genere un error, y luego envíe

164
00:12:13,975 --> 00:12:19,368
una respuesta de error apropiada a ese lado del cliente y

165
00:12:19,368 --> 00:12:24,010
será redirigido al controlador de errores.

166
00:12:24,010 --> 00:12:28,450
Entonces, esta redirección al controlador de errores se realizará llamando a Next

167
00:12:28,450 --> 00:12:32,490
con el error como parámetro para ese Next aquí.

168
00:12:32,490 --> 00:12:38,240
Entonces el Siguiente es exactamente este Siguiente que vemos en el recurso de solicitud Siguiente aquí.

169
00:12:38,240 --> 00:12:42,760
Y así, eso lo llevará hasta el controlador de errores,

170
00:12:42,760 --> 00:12:48,170
que manejará el error y luego enviará el mensaje de error de vuelta al lado del cliente,

171
00:12:48,170 --> 00:12:51,820
indicando el error de la autenticación.

172
00:12:51,820 --> 00:12:56,720
Así es como

173
00:12:56,720 --> 00:13:03,435
funciona su autorización básica típica o autenticación básica en su aplicación del lado del servidor.

174
00:13:03,435 --> 00:13:08,305
Habiendo entendido esto, pasemos al ejercicio donde

175
00:13:08,305 --> 00:13:13,176
implementaremos la autenticación básica en nuestra aplicación y

176
00:13:13,176 --> 00:13:15,717
veremos cómo autentica a los usuarios.

177
00:13:15,717 --> 00:13:17,952
[ MÚSICA]