[MUSIC]
El servidor Express REST API que implementamos en el
módulo anterior permite a cualquier usuario realizar cualquiera de las operaciones GET, POST o DELETE.
No hay control sobre quién puede realizar esta operación.
Lo que significa que,
si ejecuta un servidor como ese, entonces cualquiera puede entrar en su servidor y
comenzar a manipular la información que está presente dentro de su base de datos.
Obviamente, esta es una situación peligrosa.
La forma en que debe implementarse el servidor es que,
necesita tener algún tipo de restricción sobre
qué tipos de usuarios podrán realizar qué tipos de operaciones.
Así que tal vez, permitiría y
un usuario autorizado solo realizar operaciones GET.
Así, por ejemplo, si quieres que un invitado pueda ver información
sobre los platos en tu restaurante o el menú de tu restaurante,
etc., eso es perfectamente aceptable.
Pero, puede permitir que solo un administrador ingrese y
modifique la información sobre el plato o elimine un plato del menú.
Y también actualice un plato existente en el menú, o una promoción,
o la información sobre los líderes en su lado del servidor.
Ahora, también podría tener otro grupo de usuarios que serán usuarios registrados
que pueden tener permiso para guardar algunos de sus platos como sus platos favoritos,
y sólo ellos serían capaces de manipular la lista de sus platos favoritos.
Así que ese es otro nivel de autorización o
autenticación que necesita realizar.
Por lo tanto, tiene diferentes grados de usuarios, y
también, dependiendo del tipo de operaciones que se les permitiría realizar.
Así que todo esto significa que necesita algún tipo de seguridad para ser
incorporado en su lado del servidor.
Vamos a ver cómo podemos autenticar a los usuarios y
luego decidir qué tipo de usuario es este cliente.
Y luego, dependiendo del tipo de usuario,
puede permitir que el usuario realice ciertos tipos de operaciones.
Comenzaremos con la comprensión básica de esto, lo que llamamos como
Autenticación Básica en un lado del servidor para
un cliente, y luego, construiremos sobre eso a lo largo del resto de este módulo.
Y luego, al final de este módulo, terminaremos con un mecanismo
, lo que permitirá a los usuarios registrarse.
Además, los usuarios registrados pueden realizar ciertas operaciones
que un usuario no registrado no puede, y así sucesivamente.
Así que vamos a imponer varios tipos de controles de acceso para
varias operaciones en el lado del servidor en función del tipo de usuario.
Así que eso te establece la perspectiva, o
más bien la idea de lo que encontrarás en este módulo.
Comencemos con la autenticación básica,
el mecanismo básico que nos permitirá autenticar a los usuarios. La
autenticación básica en HTTP es un mecanismo muy simple,
que pedirá al usuario un nombre de usuario y
contraseña para ser enviado con una solicitud.
Y hay una estructura específica
sobre cómo se enviará esta información desde el cliente al lado del servidor.
Por lo tanto, esta es una cuestión, la autenticación de acceso básica, que admite HTTP,
es una cuestión que permitirá a un servidor desafiar a un cliente, y pedir
el nombre de usuario y la contraseña para ser enviado por el cliente.
Por lo tanto, el servidor puede desafiar al cliente a autenticarse escribiendo esta
información.
El cliente necesita enviar el nombre de usuario y la
contraseña en respuesta al desafío desde el lado del servidor.
Por lo tanto, cada mensaje de solicitud que se origina desde un cliente
debe incluir la forma codificada del nombre de usuario y
la contraseña en el encabezado de solicitud que va del cliente al lado del servidor.
Por lo tanto, cuando el servidor recibe
la solicitud, el servidor extraerá esta información del encabezado de solicitud del cliente.
Y luego, use eso para autenticar el cliente antes de
permitir el acceso a las diversas operaciones en el lado del servidor.
Entonces, ¿cómo funciona esta autenticación?
Si un cliente envía una solicitud al servidor, y
esta solicitud de cliente no incluye la formación de autorización, entonces el servidor
desafiará al cliente, está pidiendo al cliente que envíe esta información.
El servidor desafía al cliente mediante la inclusión de
un encabezado en el mensaje de respuesta entrante.
El encabezado con el tipo como WWW-Authenticate, y
luego la segunda parte donde especifica el tipo es donde
especificará qué tipo de autenticación debe enviar el cliente.
Y comenzaremos con la comprensión de la autenticación básica aquí.
Y también observe que el mensaje de respuesta contendrá un código de error 401,
que no es autorizado, que significa no autorizado.
Entonces, cuando la respuesta regresa desde el lado del servidor, entonces el cliente,
en respuesta a esta respuesta entrando, el cliente tendrá que enviar su solicitud,
incluyendo un campo de encabezado específico en el mensaje de solicitud de la autorización de tipo.
Y este campo de encabezado de autorización contendrá cierta información allí.
Para una autenticación básica, esta información sería en la forma de,
como la primera palabra aquí, será Básico.
Y luego seguido de un espacio aquí, y seguido de una cadena codificada Base64 aquí.
Esta cadena codificada en Base64 codifica el nombre de usuario y la
contraseña en un formato particular, y luego lo incluye en el encabezado.
Ahora estás diciendo, si envías un mensaje de solicitud como este,
incluyendo este, en el encabezado, entonces cualquiera en el medio.
Así que si usted sabe algo acerca de la seguridad y
cómo el hombre en el medio ataque puede ser lanzado, entonces obviamente,
esto puede ser recuperado por un intruso en el medio,
y luego puede ser usado para falsificar al cliente real.
Una vez más, no estamos entrando en esa cuestión en este momento.
Cuando hablo de HTTPS en el siguiente módulo,
volveré para abordar ese problema con un poco más de detalle.
Pero por el momento, la información en el encabezado será enviada
sin ser encriptada en el encabezado en este momento.
Ahora, otra razón por la que estoy haciendo esto es que, para que podamos realmente mirar
el encabezado directamente y luego ver esta información en el encabezado mismo.
Por lo tanto, cuando el cliente envía esta solicitud, el servidor extraerá
la información de este encabezado de autorización en el encabezado de solicitud.
Y luego use esta información para verificar si se trata de
una solicitud de cliente autorizada o no.
Ahora, por supuesto, su siguiente pregunta sería,
¿qué contiene exactamente este encabezado de autorización?
El encabezado de autorización en sí se construye de la siguiente manera.
Si tiene un nombre de usuario y una contraseña, estos son los dos
elementos de información que utilizará para autenticar un cliente.
Por lo tanto, el nombre de usuario y la contraseña se concatenarán en una
sola cadena diciendo nombre de usuario y dos puntos, y la contraseña misma.
Entonces la cadena de nombre de usuario, dos puntos y
contraseña se concatenarán juntos en una cadena completa aquí.
Esta cadena resultante que obtenemos aquí es esa, codificada usando codificación Base64.
Si sabe acerca de cómo se realiza la codificación conceptos básicos para la codificación,
conviértalo en un encabezado ASCII como se muestra en este ejemplo aquí, por
lo que esto no es más que una cadena de encabezados ASCII.
Ahora, si no sabe mucho sobre la codificación rígida básica, no se preocupe por
ello, no afecta su comprensión de lo que está pasando aquí de todos modos.
Entonces, este Basic64 codificó cadenas, por lo que
esta información en particular se codifica en una cadena como esta, y
luego se enmarca en el encabezado de solicitud que va del cliente al servidor.
El encabezado de solicitud en sí es de la autorización de tipo,
y luego seguido por el valor real aquí, que dice,
Basic, y un espacio aquí, y la cadena codificada Base64 aquí.
Por lo tanto, cuando esto sea recibido por nuestro servidor, el servidor extraerá esta información,
y luego de aquí, extraerá el nombre de usuario y la contraseña, y
luego verificará si coincide con un usuario autorizado o no en el lado del servidor.
Para ayudarle a entender mejor cómo organizamos realmente la aplicación express
y cómo se lleva a cabo la autenticación en sí, como hemos aprendido anteriormente,
las aplicaciones express se organizan en un conjunto de middleware.
Y la forma en que funciona la aplicación express es que el middleware
se aplica a la solicitud y al mensaje de respuesta
en el orden en que se declara en mi aplicación expresa.
Entonces, si tiene un express.use y
luego tiene el primero que dice un servidor estático, luego de eso,
tiene otro middleware, luego de eso, tiene otro middleware.
La secuencia en la que se declaran en el archivo app.js de servidores rápidos,
por ejemplo, es la secuencia exacta en la que se aplicará el middleware.
Entonces, una solicitud entrante desde el lado del servidor como recuerda en su
aplicación expresa, la solicitud entrante se trata como un objeto de solicitud.
El objeto de respuesta es lo que construye
el servidor express, y luego el siguiente le permite pasar al siguiente middleware
que va a aplicar, y así sucesivamente.
Entonces, una solicitud entrante como esta, cuando entra, se aplica el primer middleware.
Y luego, una vez que ese middleware ha transformado tanto
la solicitud como la respuesta, pasa al siguiente middleware, que luego se aplica a él.
Así, por ejemplo, vimos que aplicamos Morgan primero,
luego aplicamos el analizador corporal al middleware.
Por lo tanto, ya deben haber transformado la solicitud y los objetos de respuesta.
Y luego, después de eso, podemos incluir un middleware de autenticación en su lugar.
El middleware de autenticación va a autenticar la solicitud.
Ahora, por lo que si está utilizando la autenticación básica, haga su solicitud
debe contener en el encabezado el encabezado de autorización en su lugar allí.
Por lo tanto, el middleware de autenticación extraerá el encabezado de autorización
y luego se comprobará para ver si el usuario está autorizado.
Y si el middleware de autenticación detecta que usted es un usuario autorizado,
se le permitirá continuar con el siguiente conjunto de
middleware que sigue el paso de autenticación.
Y sus registros serán procesados por el middleware posterior.
Pero por otro lado,
si su middleware de autenticación decide que no es un usuario autorizado,
entonces el middleware de autenticación lo llevará a lo largo de una ruta diferente.
Y luego genere un error, y luego envíe
una respuesta de error apropiada a ese lado del cliente y
será redirigido al controlador de errores.
Entonces, esta redirección al controlador de errores se realizará llamando a Next
con el error como parámetro para ese Next aquí.
Entonces el Siguiente es exactamente este Siguiente que vemos en el recurso de solicitud Siguiente aquí.
Y así, eso lo llevará hasta el controlador de errores,
que manejará el error y luego enviará el mensaje de error de vuelta al lado del cliente,
indicando el error de la autenticación.
Así es como
funciona su autorización básica típica o autenticación básica en su aplicación del lado del servidor.
Habiendo entendido esto, pasemos al ejercicio donde
implementaremos la autenticación básica en nuestra aplicación y
veremos cómo autentica a los usuarios.
[ MÚSICA]