[MUSIC]
Ya habíamos desarrollado un servidor API REST completo usando Express y
MongoDB como parte de este curso.
Para que el servidor pueda comunicarse de manera significativa con nuestro cliente,
haremos algunos ajustes menores para que devuelva el tipo correcto de datos.
Para que la implementación de nuestros clientes pueda trabajar de manera más eficiente
con los datos devueltos desde nuestro lado del servidor.
Así que para hacer eso,
trabajemos en algunos ajustes a nuestro lado del servidor en este ejercicio.
Ir a nuestro servidor en el editor, antes de comenzar a trabajar en el servidor,
le sugiero que descargue todas las imágenes que he proporcionado
como un archivo zip en los recursos del ejercicio llamados images.zip.
Descomprima el archivo y luego obtenga todas las imágenes desde allí, y
luego copie esas imágenes en la carpeta de imágenes públicas en nuestro servidor.
Así que ves que aquí he copiado todas las imágenes en mi
carpeta de imágenes públicas aquí ya.
Porque nuestro servidor es el que va a servir todas estas imágenes para
nuestra aplicación cliente.
A continuación, vamos a los cors y ajustamos esa lista blanca, aquí.
Entonces, para nuestra aplicación cliente angular, si la iniciamos
con el comando ng serve, se ejecuta en localhost: 4200.
Por lo tanto, cualquier solicitud que llegue desde nuestra
aplicación angular al servidor llevará eso como su origen allí.
Así que es por eso que voy a agregar eso en mi lista blanca, para
que cualquier problema cors se solucione automáticamente.
Así que entrando en ese archivo cors.js,
en mi lista blanca, aquí, permítanme agregar en
el http://localhost:, 4200.
Y este es el origen desde el cual todo mi cliente angular
originará la solicitud que viene a este servidor.
Así que de esa manera, mis cors no causarán problemas para mayo cliente angular.
A continuación, necesitamos actualizar algunas de las rutas para manejar
los parámetros de consulta, y también algunos otros ajustes menores.
Permítanme comenzar con los archivos promoRouter.js.
Así que es fácil actualizarse.
Así que yendo al archivo promoRouter.js, en el archivo PromoRouter, para
la solicitud get que obtenemos aquí,
en lugar de hacer promotions.Find con un JavaScript vacío,
aquí proporcionaría el req.query como
parámetro para que promotions.Find aquí.
Lo mismo con el LeaderRouter también, así que déjame ir al archivo leaderRouter.js.
Y en LeaderRouter también,
aquí donde encontrará Leaders.Find con el objeto JavaScript vacío.
En su lugar, reemplace eso con ese req.query, para
que se pasen los parámetros de consulta.
Así que aquí es donde pasaremos la columna destacada
como el parámetro de consulta.
Ahora habiendo ajustado estos dos, ahora trabajemos en la ruta del plato,
así que vamos al archivo dishRouter.js, incluso en el DishRouter, la misma actualización aquí.
Así que ir a este plate.Find en el método get aquí, cambie eso a req.query.
Entonces, con esto, mi actualización de DishRouter se ha completado.
Así que ahora hemos actualizado el PromoRouter, el ReaderRouter, y
el DishRouter, entonces vamos a pasar a actualizar ese FavoriterOuter.
Ahora habría implementado el router favorito como parte de su
cuarta asignación.
Ahora en FavorIterOuter, verá que para
FavorIterOuter no le estoy mostrando el parter restante porque
debería haber hecho como parte de su asignación.
Permítanme primero llamar su atención sobre el método get para
Favoriterouter.route («/:dishid').
Ahora, voy a usar este método get
para verificar que el plato específico con
un DishiD ya sea un favorito para el usuario.
Entonces, en lugar de simplemente decir que la operación GET no es compatible,
solo voy a aprovechar la presencia de esta operación get.
Y luego vamos a decir,
Favoritos.Findone.
Y diré,
usuario: req.user.id
Así que encontraremos los favoritos para ese usuario en particular.
Y luego diremos, .entonces, favoritos.
Y, catch ((err),
next (err)).
Y luego de manera similar aquí, agregaremos el error aquí.
Siguiente (err)), aquí.
Así que dentro de esto .then, cuando obtengamos los favoritos,
entonces verificaremos, si (! favoritos).
Por lo tanto, si no hay favoritos para este usuario,
entonces obviamente el plato que estamos comprobando no existe.
Así que regresaremos, Res.statusCode, 200.
SetHeader ('Content-Type
'' application/json ').
Y luego volveremos,
Decir, «existe»: falso.
Entonces, lo que estamos especificando aquí es que si el get se hace
a este punto final con un DishiD, esta bandera existe aquí
se establecerá en true si este plato es parte de mis favoritos.
Si este plato no es parte de mis favoritos, estableceré la bandera existe en falso.
Así que aquí, ves que dado que no tengo ningún favorito, por lo que
existe debería ser automáticamente falso en este punto.
Entonces diremos «existe»: falso, y luego devolveremos los favoritos, aquí.
Bueno, obviamente en este caso,
los favoritos serían nulos en este punto, de lo contrario.
Entonces, lo que significa que los favoritos no son nulos, así que diremos if,
(favorites.dish .indexOf),
así que vamos a buscar req.params.
Deshid, así que vamos a buscar esto.
Favorites.dishes.array, para ver si el plato existe allí.
Y si no existe, obviamente esto devolverá un índice negativo aquí.
Así que en ese caso también, volveré exactamente lo mismo que aquí.
Entonces, si devuelve un índice negativo,
entonces eso significa que a pesar de que este usuario en particular tiene un centro favorito.
Este plato específico no existe en la lista de
su favorito, así que es por eso que va a volver existir falso aquí.
Ahora de lo contrario eso significa que el plato existe en la lista de favoritos.
Entonces, en este caso, devolveré el código de estado 200 existe es verdadero.
Así, cuando el usuario realiza una operación get en
este punto final con el /favorite/dishid.
Donde se suministra el DISHID como parámetro aquí.
Como parámetro de registros aquí,
entonces vamos a comprobar si ese plato existe en los favoritos.
Si ninguno de los favoritos existe para este usuario, entonces devolveremos un false.
Del mismo modo, si los favoritos existen,
pero ese plato en particular no existe en los favoritos, entonces devolverá un falso.
De lo contrario, devolverá un verdadero.
Así que esta bandera existe puede ser utilizada por mi cliente
para comprobar si este plato es parte de la lista de platos favoritos para este usuario o no.
Finalmente actualizaremos el archivo users.js.
Ahora en el archivo users.js, tenemos que agregar
otro campo router.options aquí porque a
veces una solicitud de publicación como vio con el inicio de sesión,
vamos a enviar las opciones primero para comprobar, especialmente con los coches,
si la solicitud de publicación será permitida.
Así que es por eso que revisarán coches, coches con opciones aquí y después.
Simplemente devolveremos
un mensaje de estado de 200 en respuesta a eso.
Por lo tanto, para cualquier endpoint bajo los usuarios si recibimos
las opciones simplemente devolverá un estado 200 aquí.
Ahora la función de inicio de sesión que habíamos implementado anteriormente.
Simplemente hemos hecho passport.authenticate ('local') aquí y
luego comprobamos los valores restantes aquí.
Ahora este passport.authenticate ('local'), si el usuario no se
autentica simplemente devuelve un mensaje no autorizado en el mensaje de respuesta.
Ahora eso puede no ser muy significativo para
el lado del cliente para mostrar esta información.
Así que es por eso que vamos a mejorar este método de inicio de sesión después del enrutador para
que la autenticación devuelva información más significativa en esta parte.
Así que para hacer eso, no vamos a hacer que el pasaporte se
autentique aquí dentro.
En su lugar, tomaremos, así que permítanme eliminarlo de allí,
y luego verán cómo actualizaré la publicación del enrutador aquí.
Así que veremos cochesWithOptions.
Y luego incluiremos el req, res y el siguiente aquí.
Y dentro de la req, res, y el
siguiente aquí, passport.authenticate,
Vamos a llamar a esto con 'local'.
Ahora, cuando llamamos a esto con local, si
se produce un error de autenticación, se puede hacer passport.authenticate para devolver el valor del error,
y también devolverá al usuario si no hay error.
Y podría ser un parámetro llamado info,
que llevará información adicional que podría ser transmitida de nuevo al usuario.
Este error se devuelve cuando hay un error genuino que se produce en
la posible autenticación.
Pero si la información del usuario se envía a passport.authenticate pero
el usuario no existe, entonces eso no se cuenta como un error.
En su lugar, se contará como el usuario no existe.
Y esa información se transmite de nuevo en el objeto info que entra.
Por lo tanto, el error se devolverá cuando haya un error genuino que ocurre durante
el proceso de autenticación.
Pero la información contendrá información si el usuario no existe y, por lo tanto,
passport.authenticate está devolviendo un mensaje diciendo que el usuario no
existe o que el nombre de usuario es incorrecto o la contraseña es incorrecta.
Y así sucesivamente, para que la información se transmita en, en el mensaje de información.
Ahora, veremos cómo esto es útil para nosotros cuando miremos el lado del cliente un
poco más tarde.
Así que en esta situación,
manejaremos esto de la siguiente manera.
Y no solo eso, cuando llamamos a este pasaporte autenticar,
también necesitamos pasar un (req, res,
next) como esa tira de tres parámetros.
Así que esta es la estructura.
Cuando necesite llamar a la autenticación de pasaporte,
espere que le transmita información como esta como un método de devolución de llamada aquí.
Así que también necesita suministrar este req, res el siguiente justo allí también.
Ahora, si esto ocurre.
Así que diremos si (err).
Entonces, si ocurre un error,
diremos return next (err) y luego dejaremos que el
manejador de errores de nuestro enrutador express se encargue de eso.
Ahora, consideraremos otras situaciones.
Si (! ), por lo que si hemos llegado a este punto, eso significa que
no fue un error que ocurrió, sino que quizás no se pudo encontrar al usuario.
Si el usuario no se encuentra entonces el usuario aquí se establecerá como nulo en este caso.
Entonces, en esa situación si el usuario no existe,
entonces necesitamos poder pasar información al lado del servidor.
Así que lo que haremos es pasar esta información en este formato,
así que voy a cortar esto desde aquí, y
luego pegarlo aquí y luego lo editaremos.
Si el usuario es nulo, entonces enviaremos de vuelta un
StatusCode 401 que significa no autorizado, y
luego devolveremos la información de éxito, falso.
Y luego no vamos a pasar de nuevo el token, vamos a pasar de nuevo el mensaje de estado.
Así que aquí vamos a decir inicio de sesión, sin éxito.
Y luego la tercera información pasará esta información,
ese objeto que recibimos aquí como la tercera parte de
ese mensaje de respuesta que enviamos de vuelta desde nuestro servidor aquí.
Por lo tanto, el indicador de éxito se restablecerá a false.
El estado se establecerá Iniciar sesión sin éxito y la información de error,
que se pasa en la información se pasará de nuevo.
Ahora tenga en cuenta que esta situación ocurrirá si el nombre de usuario y
la contraseña son incorrectos.
Y por lo tanto, esto no es un error, en el sentido del error, pero el hecho de que el autenticado
no pudo encontrar el usuario o la contraseña del usuario es incorrecto.
Así que esa información será codificada en la entrada que entra, y así
voy a pasar de nuevo como un error al lado de mi cliente.
De lo contrario, parte se
maneja como req.login.
Por lo tanto, si esto es exitoso,
passport.authenticate agregará este método llamado req.login al usuario.
Así que en este punto simplemente pasaremos el objeto de usuario que hemos obtenido.
Así que aquí, si hemos llegado a este punto,
entonces eso significa que el objeto de usuario no es nulo y
tampoco se produjo ningún error, por lo que significa que
el usuario puede iniciar sesión y por lo que decimos err.
Por lo tanto, intentará iniciar sesión con el usuario.
Así que diremos si erran.
Y luego pasaremos el mismo tipo de información de error que hicimos aquí.
Entonces, en este caso, si el error.
Si se produce un error, pasaremos el código de estado 401 y
diremos que el éxito es falso y el estado es Iniciar sesión sin éxito.
Y luego la información de error
vamos a pasar esto ya que en lugar de
información que vamos a pasar no pudo iniciar sesión usuario.
Entonces ese es el mensaje que pasará aquí, si se produce el error.
De lo contrario, estaríamos abajo aquí abajo.
Y entonces en este punto seríamos capaces de generar el token.
Así que si hemos llegado hasta este punto eso significa que el usuario ha
iniciado sesión con éxito y por lo tanto ahora podemos generar el token.
Por lo tanto, generaremos el token basado en el ID de usuario y
luego devolveremos ese token al usuario.
Así que aquí vamos a decir var token.
Y luego podemos decir Res.statusCode = 200, y luego res.json (éxito) es verdadero,
lo que significa que el usuario inició sesión con éxito.
Y entonces el estado sería Inicio de sesión exitoso, y
luego la tercera parte en lugar del error, pasaré el token de nuevo al usuario.
Así que diremos token, token,
este token que acabamos de obtener antes, de modo que a token se pasará
como la propiedad token del mensaje de luz de rip.
Así que aquí, observe que este eje está establecido en true.
Entonces, lo que significa que el usuario inició sesión con éxito.
Y así el usuario puede seguir adelante en este punto.
Y esto tiene que hacerse dentro del req.login aquí.
Así que en este punto vamos a cerrar el req.login.
Así que note que esto está dentro de este req.login aquí.
Así que ahí dentro pasaremos estos tres de vuelta.
Así que déjame sangrar tres líneas.
Y así es como manejaríamos el inicio de sesión de los usuarios.
Así que de nuevo, revisando este código una vez más.
Así que haremos la publicación del enrutador, pero
en lugar de hacer la autenticación del pasaporte justo allí, diremos req, res,
siguiente y luego dentro de aquí haremos un pasaporte.authenticate para el local.
Y esta autenticación pasará de nuevo, por lo que podemos proporcionar una función de devolución de llamada a eso.
Y esta función de devolución de llamada devolverá el error, el usuario o
la información aquí.
Por lo tanto, si se produce un error, permitiremos que el manejador de errores expresos se
encargue de eso.
Si el usuario es nulo, eso significa que el inicio de sesión del usuario no tuvo éxito,
y el motivo de eso estará en la información, por lo que pasará como
el error de información en el mensaje del plan aquí.
Si llegamos a este punto, el usuario se verifica con éxito.
Entonces iniciaremos sesión al usuario.
Así que el passport.authenticate agregará este método llamado Login
al mensaje de solicitud, por lo que podemos llamar al inicio de sesión con el usuario y
si esto devuelve un error, entonces devolveremos el error aquí apropiadamente.
Si no, entonces habríamos llegado al punto en el que el usuario se
autentica correctamente para que pueda generar el token web JSON aquí y devolver el
token web JSON al usuario para confirmar que el usuario se ha registrado correctamente.
Así que ese es el conjunto de pasos que vamos a usar aquí.
Ahora, la razón por la que hago una forma más elaborada de manejarlo es que quiero
distinguir entre la situación en la que ocurre un error genuino durante
el proceso de solicitud, a diferencia de la situación en la que el nombre de usuario no es válido,
o la contraseña no es válida.
Así que esos dos casos serán manejados por esta situación en la que la información
nos llevará la información de vuelta.
Así que eso no es un error perse, pero esa es una situación en
la que el usuario no es un usuario válido o la contraseña del usuario no es válida.
Así es como manejarán el proceso de inicio de sesión del usuario.
Además, agregaré un método más aquí llamado,
CheckJWToken.
Es muy posible que mientras el cliente haya iniciado sesión y
obtenido el token web JSON, en algún momento más tarde, el token web JSON puede caducar.
Por lo tanto, si el usuario intenta acceder desde el lado del cliente con un token caducado
al servidor, entonces el servidor no podrá autenticar al usuario.
Por lo tanto, a intervalos periódicos, es posible que desee realizar una comprobación cruzada para asegurarnos de que el
token web JSON siga siendo válido.
Entonces, esa es la razón por la que estoy incluyendo otro punto final llamado
CheckJWTToken, por lo que si haces un llegar al CheckJWTToken.
Al incluir el token en el encabezado de autorización
, esta llamada devolverá un verdadero o falso para indicarle
si el token web JSON sigue siendo válido o no.
Si no es válido, el lado del cliente puede iniciar otro inicio de sesión para
que el usuario obtenga un nuevo token web JSON, si es necesario.
Entonces, para hacer esto, diremos cors, CorsWithOptions y,
req, res, aquí, como se esperaba.
Y aquí vamos a decir,
passport.authenticate ('jwt',
Y, {sesión: false}).
Y esto devolvería err, usuario, información.
Así que recuerde cómo usamos el autenticador de Passport antes.
Así que la sesión de JWT cae aquí.
Así que antes aquí decimos, passport.authenticate local.
Así que esto es para la autenticación local.
Entonces esto es para la autenticación de token web JSON.
Entonces, cuando llamemos a eso, ya que eso va a verificar el token web JSON,
así que voy a decir, si (err), vuelva a continuación (err).
Y luego deje que el controlador de errores Express se ocupe de esa situación.
Y luego diremos, si (! usuario),
Si el usuario no existe, entonces de manera similar, de lo contrario.
Entonces, lo que significa que si el objeto de usuario se encontró desde el token web JSON y
luego se cargó en el req.user, entonces eso significa que el usuario es un usuario válido.
Y así se puede permitir que siga adelante.
De lo contrario, vamos a decir que el usuario no existe.
Por lo tanto, tenemos que inferir que el token web JSON ha caducado.
Así que en este punto, enviaremos una resolución con el código de estado de,
401, tan no autorizado.
SetHeader (, 'Content-Type',
'application/json').
Y luego devolveremos res,
.json, diremos, {status:,
'JWT inválido! '.
Y luego devolveremos una bandera llamada éxito: falso.
Y luego, Vamos a devolver la información que
obtenemos si el usuario no está autenticado como el error en este punto.
De lo contrario, eso significa que llegamos a este punto cuando el usuario es un usuario válido.
Entonces, en este caso, déjame copiar ese código aquí,
estaremos enviando un código de estado de 200, y
luego el res.json enviará JWT,
¡válido! , y el éxito será cierto.
Y la tercera parte, enviaremos la información del usuario.
De esa manera, cuando se llama a este extremo
con el método get, esto verificará si el token es válido o no.
Si el token es válido, entonces recibirá esta respuesta.
Y desde el indicador de éxito en la respuesta,
puede verificar si el token web JSON es válido o no.
Y esto es útil en el lado del cliente.
Ahora este pasaporte aquí, passport.authenticate aquí,
tendrá que ser suministrado con req y res como los dos parámetros aquí.
Así es como llamamos a ese passport.authenticate.
Observe que cada vez que llame a passport.authenticate y
espere esta función de devolución de llamada aquí, debe anexar este punto, req,
.res, a ese passport.authenticate, y luego volver aquí.
Así que con esto, hemos actualizado todo en el lado del servidor.
Así que vamos a guardar todos los cambios en el lado del servidor.
Así que ahora nuestro servidor está listo para
manejar las solicitudes entrantes de nuestro cliente Angular.
Con esto, completamos este ejercicio.
En este ejercicio, ahora hemos preparado nuestro servidor Express para
manejar las solicitudes entrantes de nuestro cliente Angular.
En el próximo ejercicio, vamos a ver el cliente angular con más detalle para
entender cómo se comunica con este servidor adicional.
Este es un buen momento para que hagas una confirmación de Git con el mensaje,
integrando cliente y servidor.
[ MÚSICA]