Esta es la segunda parte del Ejercicio de Sesiones Expresas.
Hemos completado la primera parte anteriormente,
donde agregamos soporte para Express Sessions,
y usamos Express Sessions como una forma de rastrear a los usuarios en el lado del servidor,
y reconocer las solicitudes entrantes de los usuarios.
En este ejercicio, no nos concentramos tanto en las propias Sesiones Express,
pero veremos una forma de ampliar nuestro servidor de API REST express
para admitir un nuevo modelo de registro y autenticación de usuarios.
Por lo tanto, vamos a introducir un nuevo modelo de usuario y esquema en nuestra aplicación.
Ya tenemos la ruta de los usuarios de barra diagonal que
el generador express ya ha montado el router de un usuario.
Por lo tanto, vamos a aprovechar eso y luego
actualizarlo para admitir el registro de nuevos usuarios,
autenticar a un usuario existente
y también cerrar sesión a un usuario de nuestro sitio de servidor.
Por lo tanto, veremos las Sesiones Express como una forma de rastrear a los usuarios una vez que el usuario inicie sesión,
y luego cuando el usuario cierre
la sesión, la sesión se eliminará del sistema.
Entonces, ¿cómo vamos a hacer esta extensión en este ejercicio?
Vamos a averiguarlo.
Continuando con nuestro servidor de API REST express,
vamos ahora a ir a los modelos y agregar un nuevo archivo llamado user.js.
Este es el archivo donde vamos a crear el esquema de usuario y el modelo.
Vamos a crear un esquema de usuario simple que rastrea el nombre de usuario
y la contraseña, y también un indicador que se establece para indicar
si el usuario es un administrador o un usuario normal.
Por lo tanto, esta es una forma de distinguir entre diferentes tipos de usuarios.
Por lo tanto, en este archivo,
primero vamos a requerir mangosta porque estamos creando un esquema de mangosta,
y luego vamos a crear un esquema llamado esquema mangosta,
y luego vamos a decir var usuario.
Así que este es el esquema de usuario que vamos a crear,
y vamos a decir nuevo esquema de usuario.
El esquema de usuario se definirá como acabo de mencionar,
con tres campos aquí llamados nombre de usuario
que obviamente serían de la cadena de tipo,
y este es un campo obligatorio,
y este es un campo único.
Usted no quiere que dos usuarios con el mismo nombre de usuario en su sistema,
por lo que creamos el nombre de usuario y luego el segundo campo es el campo de contraseña.
Ahora, por supuesto, puede ampliar
este esquema de usuario para permitir al usuario realizar un seguimiento de todo su perfil,
pero lo haremos en uno de los ejercicios posteriores, por el momento,
un usuario es reconocido dentro del sistema simplemente por el nombre de usuario y la contraseña.
Por lo tanto, la contraseña es de la cadena de tipo y luego es necesaria.
El tercer campo que voy a usar se llama admin.
Entonces, el administrador es del tipo booleano,
y diremos por defecto false.
Por lo tanto, de forma predeterminada cuando se crea
un usuario, se crea un nuevo usuario,
el indicador de administrador se establecerá en false.
Puede establecerlo explícitamente
en true desde su código para marcar a un usuario como usuario administrativo.
Tal vez usted podría proporcionar privilegios adicionales a un usuario administrativo,
o tal vez permitir que el usuario administrador realice
ciertas operaciones que los usuarios normales no lo harían.
Vamos a ver que en uno de los ejercicios posteriores,
por el momento, este es el esquema de usuario que hemos creado,
vamos a crear un módulo de este y exportar desde
este módulo un modelo de mangosta del nombre usuario.
Por lo tanto, este es el modelo de Mangosta y el esquema es
el esquema de usuario que acabamos de definir un poco antes.
Por lo tanto, así es como definimos nuestro esquema de usuario.
Por lo tanto, ahora que hemos definido nuestro esquema de usuario,
vamos a entrar en el router que ya ha sido configurado
por el generador express cuando genera esta aplicación express.
Por lo tanto, si va a la carpeta de rutas,
verá este archivo llamado users.js.
Por lo tanto, este archivo users.js se extenderá para crear el enrutador.
Entonces, justo ahí lo que voy a hacer es importar el analizador corporal,
y luego declararán el enrutador express,
y luego diremos también importar
el esquema de usuario y el
modelo del usuario de modelos,
y luego para el enrutador express diremos,
enrutador use analizador corporal.
Así que, ahora que hemos declarado el analizador corporal allí,
vamos a dejar esta parte como tal,
más adelante lo modificaremos para permitir
que el administrador pueda recuperar a todos los usuarios registrados en el sistema pero por el momento,
saldremos de esa ruta como tal.
Agregaremos algunas rutas más aquí,
así que diremos, «Publicación del enrutador».
Así que vamos a apoyar la operación de publicación en una ruta llamada registro y, como es de esperar,
esta ruta de registro permitirá a un usuario
registrarse en el sistema, por lo que esto apoyará el registro del usuario.
Entonces, diremos, «Rec, res, siguiente».
Y por lo que este sería el registro posterior al enrutador,
los métodos restantes no se permitirán en la parte final de registro.
Por lo tanto, para acceder a
esto, ya que este enrutador de usuarios está montado en usuarios de barra
diagonal, especificaríamos este punto final como usuarios de barra barra barra barra barra de registro,
y este es el punto final que se utilizará para registrar nuevos usuarios dentro del sistema. Por lo
tanto, lo primero que haremos es usar
el método de usuario y la expectativa es que para que un usuario se registre,
el nombre de usuario y la contraseña se proporcionarán como una cadena JSON
dentro del cuerpo de la solicitud de correo entrante.
Por lo tanto,
desde el cuerpo, ya que el cuerpo ya habría sido analizado por el analizador del cuerpo, por
lo que desde el cuerpo,
primero verificará para asegurarse de que
el usuario con ese nombre de usuario no existe dentro del sistema.
Si el usuario con ese nombre de usuario existe,
entonces usted está tratando de registrar un usuario duplicado
y eso no debería estar permitido en el sistema.
Por lo tanto, diremos, «Los usuarios encuentran uno», y luego intentaremos encontrar si
hay un usuario con el nombre de usuario que ha sido
seleccionado por el cliente que está tratando de registrar a un nuevo usuario.
Si el usuario ya existe,
entonces obviamente no permitirá que el nuevo usuario se registre con el mismo nombre de usuario.
Entonces, diremos: «Entonces usuario».
Por lo tanto, esto devolverá al usuario aquí y dentro de este campo de usuario,
luego verificaremos el hecho de si el usuario ya existe,
y luego déjame atrapar el error aquí.
Así que diremos, «Error de captura», y luego, «siguiente error».
Entonces, solo pasaremos eso al manejador de errores allí.
Por lo tanto, si esta búsqueda para el usuario devuelve el campo de usuario,
si el usuario no es igual a nulo.
Por lo tanto, si el usuario que es devuelto por esta búsqueda
no es nulo entonces eso significa que el usuario con ese nombre de usuario dado ya existe,
por lo que no debe permitir un registro duplicado.
Así que diremos, «Var errr nuevo error.»
Y diremos, «Usuario req. nombre de usuario cuerpo».
Ya existe. Entonces, básicamente,
está evitando que un usuario duplicado se registre y luego diremos
err.status 403 versus el prohibido y luego salga,
llamando al controlador de errores, siguiente error.
De lo contrario, esto significa que el usuario no existe,
por lo que debe permitir que el usuario se cierre de sesión.
Entonces, en la otra parte,
diremos, devuelva user.create ().
Crearemos un nuevo usuario con el nombre de usuario establecido en req.body.username,
y luego déjame poner esto en la siguiente línea para que quede más claro para usted,
y diremos contraseña: req.body.password.
Ahora, ya sabemos que el indicador admin por defecto se establecerá en false,
así que vamos a dejarlo como tal,
y esto permitirá que nuestro nuevo usuario se registre y cuando el nuevo usuario esté registrado,
esto devolverá una promesa y dentro del «entonces» manejaremos esta promesa aquí.
Entonces, esto devolverá la promesa de
este «entonces» y luego lo manejaremos en el siguiente «entonces» aquí.
Dirá entonces, Res.StatusCode es 200,
Res.setHeader y diremos Content-type application/json
y diremos, res.json (estado: Registro exitoso),
y si lo desea,
podemos cargar al usuario en
este mensaje de respuesta aquí como una propiedad en el json.
Dirá Registro exitoso.
Entonces, si hay un error en
esta operación, dirá «siguiente error».
Así que eso manejará el error.
Si la promesa no se resuelve correctamente,
entonces será manejada por eso. Así que eso es todo.
Así que aquí, tenemos una forma de que el usuario se registre.
Por lo tanto, para que el usuario se registre,
el usuario hará una publicación en /users/signup y en el cuerpo del mensaje,
el cliente incluirá una cadena json
con propiedades de nombre de usuario y contraseña en esa cadena json.
Así es como te registras para un nuevo usuario.
Ahora, veamos cómo iniciaremos sesión en el usuario.
Ahora, seguiremos utilizando las sesiones Express que hemos hecho antes para rastrear al usuario.
Por lo tanto, para registrar un usuario dirá «router.post» en el punto final/inicio de sesión.
Entonces, en el endpoint /login,
haremos un router.post.
Obviamente, en lugar de decir función,
puede usar la función de flecha aquí para el router.post,
voy a hacer lo mismo aquí.
Me han encariñado las funciones de flecha.
Por lo tanto, vamos a hacer una función de flecha aquí.
Entonces, para el inicio de sesión, ¿cómo continúa el inicio de sesión?
Así que para el inicio de sesión,
lo que haremos es que iremos al archivo app.js y luego dentro de esta autenticación,
estábamos haciendo ese registro para el usuario allí.
Así que, lo que voy a hacer es copiar
todo esto porque no estaría haciendo todo esto de todos modos.
Por lo tanto, más bien permítanme copiar todo el camino desde este punto en adelante hasta el req.session.user.
Por lo tanto, la si parte de req.session.user voy a copiar,
y luego venir al users.js y para el inicio de sesión.
Es exactamente como voy a hacer la autenticación.
Así que diremos si no req.session.user.
Así que eso significa que el usuario aún no se ha autenticado a sí mismo.
A continuación, espera que la autenticación básica sea
un mecanismo para que el usuario utilice para la autenticación.
Así que vamos a decir var AuthHeader if! AuthHeader entonces levantaremos el error, de
lo contrario recuperaremos el nombre de usuario y la contraseña del encabezado.
Ahora, aquí estábamos haciendo si el nombre de usuario es igual a admin y la contraseña es igual a contraseña.
Pero ahora, lo que vamos a hacer es buscar en
la base de datos para ver si ese usuario en particular existe.
Entonces, en lugar de hacer esto aquí,
en lugar de hacer esto si nombre de usuario y contraseña,
diremos, User.Findone
y diremos que nombre de usuario es nombre de usuario.
Así que esta propiedad es igual a este nombre de usuario que acabamos de recuperar
y luego diremos entonces usuario.
Así que dentro de este «entonces».
Así que voy a mover este código dentro de este «entonces» porque
ahora lo que voy a verificar es ahora que he recuperado al usuario,
necesito verificar para asegurarme de que este usuario sea exactamente lo que estoy buscando.
Así que en este punto,
primero vamos a verificar para asegurarnos de que el usuario no es nulo.
Entonces diremos si el usuario es nulo.
Por lo tanto, si el usuario es nulo,
lo que significa que no pudimos encontrar un usuario con ese nombre de usuario en particular.
Por lo tanto, tendrá que devolver un error aquí.
Así que déjame copiar esta parte y luego pegarla
aquí y luego volveremos diciendo var nuevo Error
y diremos que el nombre de
usuario del espacio de usuario
no existe.
Entonces, en este caso,
este usuario no existe, así que solo voy a eliminar esta parte y
luego el estado de error correspondiente sería 403 aquí.
Así que esta es la primera parte.
Si el usuario es nulo, obviamente vamos a decir que el usuario no existe.
La segunda parte que vamos a comprobar es Else if user password.
Entonces, lo que significa que el usuario existe en este punto.
Por lo tanto, la segunda comprobación que haremos es que la contraseña del usuario no es
igual a la contraseña entonces.
Una vez más necesitamos indicar el error allí.
Entonces, el error sería decir,
en este caso, diremos
«su contraseña es incorrecta».
Así que esa es la segunda parte aquí.
Entonces su contraseña es incorrecta y luego la última parte.
Vamos a decir «otra cosa».
Así que déjame sangrar este código.
De lo contrario, si
user.username es nombre de usuario que obviamente debería ser cierto en este caso.
Luego, la segunda parte,
user.password es igual a contraseña que también obviamente debería ser correcta en este punto.
Pero en cualquier caso,
voy a verificar ese problema aquí y esto no ocurrirá en absoluto en este caso.
Por lo tanto, en el momento en que llegue a este punto,
el nombre de
usuario debe ser el mismo que el nombre de usuario y la contraseña debe ser el mismo que una contraseña,
pero en cualquier caso pongo una doble comprobación en ese punto solo para estar doblemente seguro.
Luego, en este caso,
diremos que req.session.user está autenticado.
Por lo tanto, estableceremos esto en autenticado
y también este, diremos
Res.statusCode es 200.
Así que pudimos autenticar con éxito al usuario.
Por lo tanto, diremos Res.statusCode es 200 y luego diremos Res.setHeader
Content-Type text plain y
res.end simplemente enviaremos un mensaje diciendo «Estás autenticado».
Eso es todo. Por lo tanto, esto cubre la parte entonces del usuario Findone.
Así que primero, comprobamos que si el usuario es nulo,
eso significa que no pudimos encontrar al usuario,
por lo que obviamente estamos devolviendo un error diciendo que el nombre de usuario no existe.
Si la contraseña del usuario no coincide con la contraseña,
por lo que en este punto,
el usuario existe pero la contraseña no coincide, por lo que diremos,
«Su contraseña es incorrecta», y luego, finalmente,
llegamos a este punto, entonces el nombre de usuario y la contraseña deben identificarse correctamente.
Aunque no necesito esta comprobación, pero simplemente la puse allí y luego en este punto,
estableceré el req.session.user para
autenticarlo y luego estableceré el código de estado en 200, lo que significa que
pudo autenticar con éxito al usuario y luego puede terminar en ese punto.
Debido a que este es un entonces,
pondré una captura en este punto,
así que diremos error catch y si se produce el error,
entonces simplemente pasaré
el error al siguiente para
que el controlador de errores pueda lidiar con el error apropiadamente.
Así que eso termina este usuario Findone.
Ahora, este es el caso cuando el req.session.user no está configurado.
Si eso ya está configurado
, significa que el usuario ya ha iniciado sesión.
Entonces, en este caso,
la parte más aquí trata de la situación diciendo que estableceremos
el StatusCode en 200
y el Content-Type en texto/plain y luego diremos:
«Ya está autenticado».
Por lo tanto, si llega a esta parte,
vendría aquí porque el req.session.user ya no es
nulo, lo que significa que el usuario ya ha sido autenticado,
lo que significa que cuando llegue a este punto,
el usuario ya ha iniciado sesión antes,
por lo que no necesita verificarlo.
Así que simplemente dirás,
«Ya estás autenticado», y luego terminarás en este punto.
Está bien. Así que ahora, el último método que vamos a implementar es para cerrar la sesión del usuario.
Por lo tanto, vamos a hacer un router.get on /logout.
Usted debe estar preguntando por qué hacemos un conseguir en
el cierre de sesión en lugar de una publicación que hicimos en el inicio de sesión? Al
iniciar sesión, debe enviar el nombre de usuario y la contraseña.
Para cerrar la sesión, simplemente está cerrando sesión usted mismo del sistema,
por lo que no necesita proporcionar más información porque
el servidor ya le está rastreando basándose en
su ID de sesión y dentro de esa cookie de sesión aquí.
Por lo tanto, es por eso que no
necesitamos explícitamente enviar ninguna información adicional en el cuerpo del mensaje.
Así que diremos si req.session lo que significa que la sesión debe existir, de
lo contrario, está tratando de cerrar la sesión de un usuario que no ha iniciado sesión.
Así que no tiene sentido.
Ahora, la sesión en sí proporciona este método
llamado destroy y cuando se llama al método destroy,
la sesión se destruye y la información se elimina
del lado del servidor perteneciente a esta sesión.
Entonces, lo que significa que si el cliente intenta volver a enviar
la información de la sesión que se almacena en forma
de una cookie firmada en el lado del cliente,
eso no será válido.
Por lo tanto, necesitamos un método para eliminar la cookie que se almacena en el lado del cliente.
Ahora, esta operación eliminará
la información de sesión del lado del servidor para que la sesión ya no sea válida.
Entonces, en este punto,
diremos req.session.destroy y luego diremos, Res.ClearCookie.
Por lo tanto, ClearCookie es una forma de pedirle al cliente que
elimine la cookie y el nombre de la cookie es el ID de sesión.
Entonces, en el ejercicio anterior,
vimos que la cookie se almacenaba con el nombre del ID de sesión en el lado del cliente.
Así que le pedimos al cliente que elimine esta cookie desde
el lado del cliente en el mensaje de respuesta y luego diremos,
res.redirect y la redireccionaremos a la página de inicio aquí.
Por lo tanto, esta es una forma de redirigir al usuario para que ingrese a su página estándar,
por ejemplo, la página de inicio de su aplicación.
Por lo tanto, esta es la forma en que manejaría el cierre de sesión del sistema.
Si el req.session no existe,
entonces eso significa que no has iniciado sesión,
por lo que tendremos que generar un error.
Entonces diremos var err,
nuevo Error, «No está conectado»,
y estableceremos el estado del error en 403,
esta es una operación prohibida y
luego generaremos el error al controlador de errores, eso es todo.
Así que ahora, vemos que hemos ampliado el router del usuario para admitir tres nuevos endpoints,
el endpoint de suscripción que permite a un usuario registrarse,
el endpoint de inicio de sesión que permite a un usuario registrado iniciar sesión,
y luego el extremo de cierre de sesión que permite a un usuario conectado cerrar sesión del sistema.
En el proceso de cierre de sesión,
está destruyendo la sesión en el lado del servidor,
también está borrando la cookie en el lado del cliente, de
modo que el cliente no se puede usar en la sesión caducada para intentar ponerse en contacto con ese servidor.
Una corrección menor en users.js,
esto debería ser var Usuario requiere.. /models/user,
recuerde que el archivo users.js está en la carpeta de rutas y luego
el archivo user.js está en
la carpeta de modelos que está arriba un nivel y luego en la carpeta de modelos.
Por lo tanto, esto debería ser... /models/user,
así que haz esa corrección menor, eso es todo.
Hemos modificado el archivo users.js,
ahora lo último que tenemos que hacer es ir y arreglar el archivo app.js.
En el archivo app.js de la aplicación,
si navega en el archivo app.js,
verá que tenemos
este índice de barra diagonal aquí y los usuarios slash aquí después de la autenticación.
Ahora, esto no funcionará para nosotros porque si necesita registrarse,
entonces el usuario se registrará e iniciará sesión antes de que se confirme la autorización, de
todos modos si el registro e inicio de sesión es para el proceso de registro,
así que voy a mover estos a arriba antes del paso de autenticación aquí.
Por lo tanto, vamos a mover esto a este lugar.
Por lo tanto, un usuario entrante puede acceder al archivo de índice
en la barra diagonal y también acceder al extremo de los usuarios sin ser autenticado,
pero cualquier otro extremo,
el usuario tiene que ser autenticado,
por lo que es la forma en que configuramos esto.
Dentro de la autenticación de la función, diremos,
«Si no req.session.user», entonces
notamos que este lugar, no estaríamos permitiendo que el usuario entre aquí sin que el usuario haya iniciado sesión.
Por lo tanto, si no req.session.user,
simplemente diríamos que no está autenticado.
Esta autenticación tiene que hacerse utilizando el método de inicio de sesión aquí.
Por lo tanto, voy a quitar toda esta parte aquí.
Por lo tanto, diremos, si no req.session.user,
diremos que no está autenticado y por lo tanto tendremos que enviar una foto tres aquí,
lo que significa que nunca debe bajar a este punto
sin que el usuario inicie sesión.
Por lo tanto, diremos que no está autenticado.
Recuerde que necesita autenticarse haciendo una POST en
el punto final de inicio de sesión de los usuarios de barra diagonal.
Entonces diremos que no está autenticado, de lo contrario,
si req.session.user es igual a,
recuerde que en la función de inicio de sesión en el
users.js hemos establecido el siguiente usuario de sesión a la cadena autenticada.
Por lo tanto, eso es lo que vamos a estar buscando.
Diremos que si req.session.user está autenticado,
diremos a continuación, de lo contrario no se autentica de nuevo.
Entonces enviaremos un mensaje prohibido. Eso es todo.
Entonces, con esta actualización,
mi archivo app.js también está listo.
Ahora, después de haber hecho estas actualizaciones,
vamos a comprobar cómo funciona nuestra aplicación ahora.
Ir al terminal,
si el servidor se está ejecutando, deténgalo y luego reinicie el servidor.
Mi servidor no se está ejecutando en este momento,
así que diré npm start,
y mi servidor debería estar en funcionamiento.
Veamos ahora cómo vamos a acceder al servidor.
Ir a Cartero, déjame hacer un GET en
localhost: 3000/platos y luego verá inmediatamente
que se queja diciendo que no está autenticado.
Obviamente, no estoy autenticado aquí.
Déjame intentar acceder solo al localhost: 3000 y verás que,
esa raíz está disponible para nosotros.
Ahora, por supuesto, queremos registrar primero un usuario y luego iniciar sesión
como el usuario y luego obtener acceso al resto de los extremos de la API REST.
Entonces, primero, déjame registrar a un usuario.
Para registrar al usuario,
necesito hacer una POST al localhost: 3000/usuarios/registro.
Para este mensaje POST,
en el cuerpo del mensaje,
necesito incluir en el cuerpo
del mensaje una cadena JSON con el nombre de usuario.
Por lo tanto, déjame iniciar sesión y
luego usaré la contraseña como contraseña.
Este es un registro válido.
Por lo tanto, cuando me registro como usuario con
esta información en forma de una cadena JSON incluida en el cuerpo del mensaje,
déjame ver que el encabezado ahora contiene aplicación de tipo de contenido,
JSON porque he configurado el JSON en
el cuerpo del mensaje y luego enviar el POST al registro.
Luego, cuando envío el POST al registro,
inmediatamente verá lo que devuelve el servidor aquí.
Entonces, ves que el servidor ha regresado diciendo,
«Registro exitoso» y en sí mismo,
me da los detalles del usuario aquí.
Entonces, este es un registro que existe en mi MongoDB y
tenga en cuenta que el tipo de modelo es el tipo de modelo de usuario que teníamos configurado.
Por lo tanto, tenemos el nombre de usuario y
la contraseña y el indicador de administrador como puede ver está establecido en falso por defecto.
Una vez que registramos al usuario,
este usuario es ahora un usuario válido.
Por lo tanto, permítanme intentar volver a POST al mismo usuario y ver qué sucede.
Entonces, cuando POSTO al mismo usuario obviamente,
desde el lado del servidor,
responde diciendo que este usuario ya existe.
Por lo tanto, puede ver que hemos configurado nuestro procedimiento de registro para no permitir al
usuario duplicar el registro con el mismo ID de usuario.
Está bien. Así que, esa es la segunda parte.
Ahora, vamos a hacer un inicio de sesión del usuario.
Para hacer un inicio de sesión del usuario,
permítanme eliminar el tipo de contenido y luego también
eliminaré el cuerpo porque para el inicio de sesión, eso no es necesario.
Por lo tanto, no relleno nada en
el encabezado y luego trato de iniciar sesión y cuando intenté iniciar sesión,
responde diciendo que no está autenticado.
Usted no está autorizado.
Ahora, necesito conectarme yo mismo.
Entonces, aquí es donde puedo usar la autenticación básica.
Entonces, en la autenticación básica,
solo voy a escribir mi nombre de usuario y
contraseña que acabo de registrar en el paso anterior y luego actualizar mi solicitud,
y luego hacer una POST en el inicio de sesión.
Entonces, cuando hago una POST en el inicio de sesión,
ves que el servidor responde diciendo: «Estás autenticado».
Entonces, en este punto,
puedo realizar las
solicitudes GET, PUT, POST y DELETE en todos los otros puntos finales.
Entonces, en este punto, si hago un GET en el extremo de los platos,
verías que esto devuelve
el campo vacío porque mi base de datos está vacía actualmente en este momento.
Permítanme borrar la autorización y también del encabezado eliminar
la autorización y luego hacer el GET y su caja de herramientas muy bien.
Por lo tanto, puede ver que ahora puedo
acceder a los puntos finales porque he iniciado sesión.
Así que ahora, déjame hacer un cierre de sesión del usuario.
Entonces, diremos, localhost: 3000 y cierre de sesión.
Tenga en cuenta también que, en las cookies,
se ha configurado una cookie en el ID de sesión justo allí.
Por lo tanto, esa cookie existe en mi sitio cliente.
Así que ahora, permítanme cerrar la sesión diciendo GET localhost: 3000/usuarios/cierre de sesión.
Por lo tanto, cuando cierre sesión del usuario,
inmediatamente verá que soy redirigido a
ese punto final localhost: 3000 y también notará que la cookie se ha ido.
Entonces, cuando miro las cookies,
ves que el localhost,
la cookie se ha ido porque desde mi lado del servidor cuando hago el cierre de sesión,
envía una cookie clara de descanso al lado del cliente y así la cookie se ha ido.
Ahora, si trato de hacer un GET
en el punto final localhost: 3000/platos,
esto no funcionará porque no estoy autenticado.
Por lo tanto, esto demuestra cómo puede extender su servidor Express para
permitir que los usuarios se registren y luego permitir que el usuario inicie sesión en el sistema,
y luego también cierre sesión del sistema.
En el lado del servidor, está rastreando a un usuario conectado usando la sesión y usando
la cookie en el lado del cliente y cuando el usuario cierra
sesión, la cookie se destruye en el lado del cliente.
Con esto, completamos este ejercicio.
Este es un buen momento para que hagas una confirmación de Git,
con el mensaje, Sesiones Express segunda parte.