[MÚSICA]
En la lección anterior, aprendimos acerca de la autenticación básica.
Vimos que en la autenticación básica el cliente tendrá que seguir
agregando explícitamente en el campo de autorización que contiene el nombre de usuario y la
contraseña para cada solicitud que el cliente envía al lado del servidor.
Ahora eso está perfectamente bien para una autenticación simple.
Las cookies son otro mecanismo que se proporciona que permite
a su servidor poder esperar que el cliente almacene cierta información en el lado del cliente e
incluya esa información explícitamente en cada solicitud saliente.
Entonces, en lugar de incluir su nombre de usuario y
contraseña codificados en base 64 como hicimos en la autenticación básica, usando cookies,
su servidor puede configurar una información explícita en el lado del cliente
que luego se incluirá en cada solicitud saliente desde el lado del cliente.
Ahora expandiendo esto aún más, si su servidor desea rastrear información sobre su
cliente, entonces el servidor puede configurar explícitamente un mecanismo de seguimiento de sesión.
Ahora, las cookies son pequeñas y no pueden almacenar mucha información allí,
y esto, por supuesto, no se puede incluir en la solicitud saliente.
Las cookies pueden incluir información básica
en el encabezado de la solicitud saliente del cliente.
Ahora, si queremos que se rastree mucha más información sobre un cliente
en el lado del servidor, entonces las sesiones expresas nos permiten hacerlo.
Vamos a estudiar más acerca de las cookies y las
sesiones Express con un poco más de detalle en esta lección y
también explorarlas más en los ejercicios que siguen a esta conferencia.
Entonces, ¿qué son las cookies HTTP?
Las cookies HTTP, como mencioné, son pequeños datos que se envían
desde un servidor web y se almacenan en el lado del cliente.
Ahora, casi todos los navegadores tienen la capacidad de admitir
el almacenamiento de cookies en el lado del cliente, e incluirlas automáticamente
en la solicitud cuando la solicitud se envía a un servidor específico.
Por lo tanto, cada solicitud posterior del
lado del cliente incluirá un nuevo encabezado allí
con la cookie en el encabezado de solicitud.
Ahora, obviamente, si usted ha visto que la prensa popular ha conseguido una mala reputación
allí, esto es, por supuesto, no completamente inmerecido.
Pero está totalmente fuera de proporción que lo que realmente es la verdad.
Así que tome cualquier cosa que lea en la prensa popular sobre las galletas y
su mala reputación con un grano de sal.
Las cookies son muy útiles para hacer muchas cosas interesantes.
Y podemos asegurarnos de que las cookies puedan tener suficiente integridad
integrada en ellas para que no puedan ser manipuladas por nadie en el medio.
Ahora, ¿cómo funciona esta inclusión de configuración de cookies en la solicitud saliente?
Cuando un cliente envía una solicitud al sitio del servidor,
si el cliente está autenticado en el sitio del servidor.
Por ejemplo, utilizando la autenticación básica,
entonces el servidor puede, a cambio, configurar una cookie.
Ahora, para configurar una cookie en el sitio del cliente, el servidor incluirá en
el mensaje de respuesta un encabezado con el encabezado de cookie enviado y
la cookie real en el encabezado.
Ahora, cuando el cliente recibe el mensaje de respuesta del servidor que contiene
el encabezado Set-Cookie, configurará la cookie en el lado del cliente. De
tal manera que cada solicitud posterior que va desde el lado del cliente
incluirá explícitamente un campo de encabezado llamado como cookie y
encabezado real que contiene como el valor,
la información de cookie que ha sido enviada por el servidor en el mensaje de respuesta.
Por lo tanto, cada mensaje de solicitud posterior llevará esta cookie en el encabezado.
Por lo tanto, cuando el servidor recibe este mensaje de solicitud, es capaz de examinar
la cookie y suponer de quién proviene esta solicitud.
Por lo tanto, es capaz de reconocer al cliente mirando la información de la cookie.
Así que aquí es donde las cookies resultan muy útiles
para poder enviar información de autorización.
Por lo tanto, al servir incluyendo nombre de usuario y contraseña como parte del
encabezado de autenticación básico en cada solicitud en curso.
La primera vez que se autentica, envía su nombre de usuario y contraseña y
el servidor configura la cookie de su lado.
Posteriormente, solo necesita incluir la cookie en la solicitud saliente.
Ahora las cookies también pueden tener una fecha de caducidad asociada a ellas.
Por lo tanto, en ese momento, la cookie se considerará caducada y
ya no será válida.
Así que esa es una forma de controlar la duración durante la
cual una autorización es válida.
Viniendo a Express mismo, ¿cómo admite Express las cookies?
Ahora, como entendemos, Express utiliza una gran cantidad de middleware.
Aquí es donde uno de los middlewares que viene llamado el analizador de cookies
llega a nuestra aplicación a las ocho.
El analizador de cookies permite al servidor configurar una cookie en el encabezado de respuesta.
Así que esto se hace usando res.cookie y el nombre y
ciertos valores y las opciones como veremos en el ejercicio más adelante.
Y así las cookies, cuando se envían desde el lado del cliente, incluidas en ese
mensaje de solicitud se analizan en el lado del servidor Express, utilizando el analizador de cookies.
El middleware del analizador de cookies,
que cuando se instala le permitirá analizar las cookies entrantes.
Y luego estas cookies entrantes se agregarán a
la solicitud como un encabezado y se pueden examinar en el lado del servidor.
Ahora, con el fin de proteger la autenticidad de la cookie,
las propias cookies pueden ser firmadas por el servidor.
Ahora, cuando el servidor firma una cookie, el servidor utiliza una clave secreta,
que solo es conocida por el lado del servidor.
Ahora bien, si sabe algo sobre seguridad informática, criptografía y
encriptación, entonces entiende lo que
significan las claves de firma y secretas y las claves públicas y todas estas cosas.
Si no lo hace, basta con decir que una clave secreta es
una cadena específica que solo el servidor conoce y nadie más sabe.
Por lo tanto, cuando un servidor cifra una cookie, utilizará una clave secreta como firma y
creará lo que se denomina código de autenticación de mensaje de clave hash.
E incluye esto en esa cookie que se envía desde el servidor al lado del cliente.
Este HMAC que se crea en el lado del servidor sólo puede ser hecho
por ese servidor específico sabiendo esa clave secreta.
Ahora, dado que el servidor es un recurso protegido,
solo el servidor conocerá la clave secreta y por lo tanto es muy fácil verificar
cuándo se envía una cookie firmada desde el lado del cliente al lado del servidor.
Por lo tanto, cuando la cookie firmada se envía desde el lado del cliente al lado del servidor,
la cookie se configurará en el lado del cliente, y
luego todas las solicitudes posteriores incluirán esta cookie firmada en el lado del cliente.
Ahora el middleware del analizador de cookies que configuramos con nuestro servidor Express
ya admite cookies firmadas.
Ahora, para esto, en el analizador de cookies, también proporcionará la clave secreta como
parámetro para el analizador de cookies cuando configure el middleware del analizador de cookies.
Por lo tanto, todas las cookies se firmarán apropiadamente y luego se enviarán.
Y cuando la cookie se analiza en el lado del servidor en el
mensaje de solicitud entrante, esto se agregará al mensaje de solicitud como req.signedCookies.
Y luego puede tener un campo específico que puede registrar en la cookie firmada.
Las cookies son una forma muy útil de
que su cliente pueda enviar información por la que su servidor reconoce al cliente.
Pero, por supuesto, las cookies tienen limitaciones.
Son de tamaño fijo, por lo que no pueden codificar mucha información
sobre el cliente que su servidor puede recuperar de la cookie.
La cookie se utiliza para simplemente recordar al servidor sobre
qué cliente está enviando la solicitud.
Ahora, si desea tener un mecanismo más elaborado para rastrear la información sobre
un cliente, entonces en el lado del servidor puede configurar lo que se llama como sesiones.
Ahora, las sesiones son un mecanismo genérico que está disponible con cualquier servidor.
En particular, analizaremos el propio Express y
cómo Express soporta la administración de sesiones en el lado del servidor.
La forma en que funciona es que la sesión de usuario está configurada en el lado del servidor.
Por lo tanto, esta sesión en sí es una combinación de una cookie y
un ID de sesión, y el lado del servidor realiza un seguimiento de la información
asociada con ese ID de sesión, o indexado por ese ID de sesión.
La información de sesión en sí puede tener cualquier
cantidad de información rastreada en el lado del servidor e indexada por esa cookie.
Entonces, cuando un cliente envía una solicitud a través del servidor, desde dentro de
la cookie se recupera el ID de sesión y eso se usa como un índice en el lado del servidor.
Por ejemplo,
si está utilizando una base de datos del lado del servidor, ese índice será el índice principal en
esa base de datos del lado del servidor en particular que realiza el seguimiento de las sesiones.
Y por lo tanto, la información adicional sobre esa sesión puede ser recuperada y
utilizada por el servidor para tomar decisiones sobre cómo
atiende la solicitud de cliente entrante.
Ahora, de forma predeterminada, las sesiones se almacenan en memoria en el sitio del servidor.
Ahora, obviamente, lo que esto significa es que si su servidor se reinicia, su memoria
se borrará y por lo tanto toda la información de la sesión se desvanecerá por completo.
Por lo tanto, muchos servidores recurrirán al
uso de algún tipo de almacenamiento permanente donde se realiza un seguimiento de la información de la sesión.
El almacenamiento permanente en el lado del servidor podría hacerse
a través de algún tipo de almacenamiento de archivos.
O incluso aproveche el hecho de que ya tiene una base de datos en el lado del servidor y
que almacena la información de la sesión en el lado del servidor.
Por ejemplo, en su MongoDB mismo.
Ahora, en el ejercicio que sigue, veremos el uso de un almacenamiento de archivos para el
seguimiento de la información de sesión en el lado del servidor.
Otro aspecto al que debe prestar atención es el hecho de que si está
teniendo una implementación de servidor distribuido en la que varios
servidores están actuando como el servidor para atender la solicitud.
A continuación, el servidor distribuidor debería poder acceder a la información de la sesión.
Cualquiera de estos servidores debería poder acceder a la información de sesión.
Por lo tanto, necesitará una herramienta de sesiones de distribuidor en el lado del servidor,
para permitirle admitir varios servidores replicados.
Especialmente esto es útil cuando estamos tratando de garantizar la fiabilidad
del funcionamiento del servidor.
Ahora de nuevo, no vamos a entrar en demasiados detalles sobre los de este
curso en particular, confiaremos en entender básicamente cómo funcionan las sesiones Express.
Viniendo específicamente a Express y
cómo se admite la administración de sesiones en Express.
Express utiliza el middleware de sesiones expresas que admite
el uso de sesiones en un servidor Express.
Ahora instala el middleware de sesiones expresas.
Y en el ejercicio, voy a usar FileStore
como una forma de almacenar permanentemente la información de la sesión.
Y así también incluiremos el módulo de nodo de almacenamiento de archivos de sesión que
nos permite usar los archivos en el lado del servidor para rastrear la información de la sesión.
Veremos los detalles en el siguiente ejercicio.
Y luego, una vez que lo hagamos, su sesión se configurará con el nuevo
servidor express declarando el middleware aquí como sesión que toma
un cierto conjunto de opciones como parámetro aquí.
Las opciones incluyen el nombre de la sesión, por lo que le daremos el ID de sesión para
la sesión en particular.
Y luego también proporcionará el secreto, una clave secreta que se utiliza para
codificar la cookie firmada que se enviará al lado del cliente.
Y luego también información adicional que incluye SaveUninitialized, que
será un indicador que se utiliza y también un indicador de reenvío que se utiliza.
En la siguiente diapositiva veremos algunos de los detalles de estas opciones.
Entonces todas estas opciones se especifican aquí.
Y si usted es FileStore como el almacenamiento permanente para sus sesiones,
entonces lo declararemos también en las opciones de sesión allí.
Así es como estableceríamos una sesión en el lado del servidor express
usando el middleware de sesión express.
Y el Middleware de sesión expresa, cuando el cliente envía esta información,
esto se analizará en el lado del servidor y
esto dará como resultado una propiedad llamada sesión que se agrega al objeto de solicitud.
Por lo tanto, esta información de sesión será accesible en el
objeto de solicitud como req.session.
Por lo tanto, el req.session llevará información adicional sobre esa sesión en particular
para ese cliente en particular.
Ahora, una vez que esta sesión, la solicitud entrante es analizada por el middleware de sesión,
la propiedad req.session se agregará al
objeto de mensaje de solicitud entrante que usa expresamente.
Entonces, después de analizar la sesión, la propiedad de sesión directa estará disponible y
podemos examinar eso también para verificar qué cliente ha enviado esta solicitud.
Cuando configuran su objeto de sesión en el sitio del servidor,
como vimos, podemos configurar varias opciones para ese sitio del servidor.
La cookie, las opciones de la cookie ID de sesión y el valor predeterminado para
la cookie serán como se muestra aquí, que es ruta: '/',
HttpOnly: true, secure: false, maxAge: null.
Así que este será el valor predeterminado de la cookie que se almacenará en el paquete
y se enviará al lado del cliente como una cookie firmada.
Y esto se incluiría en cada solicitud entrante desde el sitio del cliente.
Entonces el genid es la función que genera el ID de sesión.
El valor predeterminado es usar el UUID del servidor como ID general.
Luego, el indicador de volver a guardar, si es cierto, obliga a que una sesión se guarde de nuevo en
la tienda incluso si no está modificada por la solicitud.
A veces, la solicitud entrante puede
contener la necesidad de modificar la información de la sesión en el lado del servidor.
Por lo tanto, si la información de la sesión se modifica, tendrá que ser persistente.
Si no, entonces no necesitas persistir.
Pero si establece el indicador de volver a guardar en true, incluso si la información de
la sesión en el servidor no se modifica por la solicitud del cliente entrante, se volverá a guardar.
El siguiente indicador que vimos fue SaveUninitialized.
Si esto es cierto, creará una sesión recién creada sin ninguna modificación
para guardar el almacén de sesiones.
Ahora estableceremos esto como false por defecto, lo que significa que solo
rastrearemos aquellas sesiones que están autorizadas en el servidor.
Ahora el secreto, como vemos, es la clave secreta que se usa para firmar la cookie,
y la tienda en sí especifica la instancia del almacén de sesión que se utiliza.
El valor predeterminado es usar en el almacén de memoria.
Puede especificar el almacén de archivos o el almacén Mongo para
almacenar esa información de sesión, etc.
Entonces, una vez que especifique esta información para su middleware de sesión express,
la sesión se configurará apropiadamente y, por lo tanto, será rastreada en el lado del servidor.
Cada solicitud de cliente se asignará a la información de sesión en
el lado del servidor cuando la solicitud del cliente sea analizada por el middleware de sesión express.
Y el req.session se agregará al objeto de solicitud.
Con esta comprensión de las cookies y las sesiones express, pasemos
al ejercicio donde veremos cómo vamos a hacer uso de las cookies primero.
Y luego veremos cómo vamos a hacer uso de las sesiones Express
dentro de nuestra aplicación Express REST API en la que hemos estado trabajando hasta ahora.
[ MÚSICA]