Tiempo para la tercera asignación en este curso.
En este módulo, hemos estado explorando la autenticación de usuarios con mucho detalle.
Ahora, en esta asignación,
vamos a trabajar más en la autenticación de usuarios.
Vamos a añadir otra categoría de cuentas llamada como administrador.
Una cuenta de administrador es una supercuenta que tiene
muchos privilegios para realizar varias operaciones.
Una cuenta de usuario normal solo puede realizar ciertas operaciones en nuestro servidor.
Del mismo modo, una solicitud no registrada procedente de un cliente
que no está conectado solo puede realizar ciertas operaciones en nuestro servidor.
Ahora, vamos a modificar nuestro servidor para
que las operaciones de obtención puedan ser realizadas por cualquiera.
No es necesario que inicie sesión en el sistema para realizar operaciones de obtención en
los distintos extremos de API de resto, excepto el envío de comentarios.
Para las operaciones restantes en los puntos finales de API restantes,
las operaciones POST put y delete,
estas serán restringidas para ser realizadas solo por usuarios administradores,
un usuario normal no puede realizar estas operaciones.
Obviamente, no quieres que un usuario ordinario envíe nuevos platos, promociones o
información de líder, o modifique la información existente,
o incluso elimine esta información existente.
Este debe ser el privilegio del administrador del sistema para nuestro servidor.
Además, nos aseguraremos de que un usuario común pueda
publicar comentarios sobre platos específicos, eso es aceptable.
Del mismo modo, un usuario común puede actualizar y eliminar los comentarios que haya publicado.
Otros usuarios o incluso el administrador no pueden actualizar o eliminar comentarios publicados por otro usuario.
Por lo tanto, esta es otra restricción que vamos a colocar en nuestro servidor.
Ahora, vamos a examinar cómo vamos a
implementar esto y cómo exactamente nuestro servidor realiza estas operaciones.
En primer lugar, te ilustraré cómo
crearías una cuenta de administrador en tu sistema.
Te darás cuenta de que tenemos que ir detrás
de escena para crear una cuenta de administrador simplemente porque,
no queremos que se cree una cuenta de administrador realizando
la operación de registro en nuestra cuenta de usuarios/registro.
Esto dejará a nuestro servidor vulnerable a los ataques.
Por lo tanto, una cuenta de administrador solo se puede configurar
detrás de escena accediendo directamente a la base de datos.
Entonces, veamos cómo hacemos
esto en la ilustración que les voy a mostrar justo después.
Ahora, para examinar nuestra base de datos,
permítanme iniciar Mongo Ripple en el símbolo del sistema,
y luego ir a la carpeta de confusión y luego déjeme
examinar los usuarios que están registrados en mi base de datos en este momento.
Por lo tanto, puede ver que solo tengo un usuario registrado.
Por lo tanto, permítanme configurar dos cuentas adicionales,
una para un usuario común,
y otra que va a ser un administrador.
Por lo tanto, registraremos el administrador y el segundo usuario también desde nuestro punto de registro, a
partir de entonces volverán a Mongo Ripple y luego configurarán la cuenta de administrador
explícitamente modificando el registro en nuestra base de datos.
Ir a Postman pin,
permítanme inscribir dos usuarios adicionales.
Por lo tanto, antes habíamos registrado a un usuario con este nombre,
así que voy a registrar a otro usuario en mi sistema,
y por lo tanto, un segundo usuario ahora está registrado correctamente.
Ahora, permítanme también registrar una cuenta de administrador.
Por lo tanto, para la cuenta de administrador,
configuraré el nombre de usuario como admin y luego registraré a un usuario administrador.
Por lo tanto, vemos que ahora hemos añadido dos cuentas nuevas a nuestro sistema.
Ir a Mongo Ripple,
permítanme repetir de nuevo el
db.user.find () y déjeme hacerlo bastante para que parezca más fácil de leer.
Entonces, cuando hago esto,
puedes ver que tenemos una cuenta de administrador aquí con el nombre de usuario como administrador.
Ignore el nombre y el apellido,
configuraré este nombre y apellido para que sean los mismos para los tres.
Luego, tenemos la otra cuenta de usuario que he configurado con el nombre de usuario aquí,
y la tercera cuenta de usuario que ya teníamos en nuestra base de datos.
Por lo tanto, ahora tenemos tres cuentas de usuario;
dos cuentas de usuario aquí,
y una cuenta de administrador.
Ahora, por supuesto, verá que en las cuentas de usuario,
tenemos este indicador llamado como el indicador de administrador que se establece en falso para
cualquier cuenta que esté registrada en este endpoint /users/registrnup.
Esta es la forma predeterminada de configurar cuentas.
No puede permitir que un usuario configure una cuenta de administrador
haciendo nada directamente en el extremo de API de resto.
En su lugar, vamos a ir detrás de escena y luego en Mongo Ripple,
voy a modificar este registro para el usuario admin
diciendo db.users.update y luego
vamos a proporcionar el nombre de usuario como admin aquí.
Por lo tanto, vamos a actualizar el registro de versículos y luego diremos {$set:
recuerde cómo estábamos manipulando el MongoDB así que
diremos {$set: {"admin»: «true»}}. Por
lo tanto, lo que estamos haciendo aquí es que estamos
buscando esta cuenta de usuario con el nombre de usuario admin,
y luego estamos configurando el indicador admin a true
aquí usando la opción $set.
Por lo tanto, así es como actualizaríamos una cuenta para ser una cuenta de administrador.
Por lo tanto, verá que esto ha modificado los resultados.
Entonces, volvamos a revisar las cuentas.
Ahora, cuando revises la cuenta,
verás que para la cuenta de administrador,
el indicador de administrador ahora está establecido en true,
así es como terminarás creando una cuenta de administrador.
Ahora, la cuenta de administrador como cabría esperar tiene privilegios adicionales.
Por lo tanto, una vez que complete esta tarea,
notará que la operación get puede ser realizada por cualquier usuario en
/dishes/dishes/aspecificdishendpoint/promotions
y /promotions/specificpromotionendpoint y de manera similar,
para los líderes en puntos también.
Pero las
operaciones POST, put y delete en estos extremos solo pueden ser realizadas por usuarios administradores.
Ahora, además, el punto final de comentarios,
permitiríamos que sólo un usuario registrado que ha iniciado sesión para
acceder a los comentarios para un plato específico,
permitiremos que un usuario conectado para publicar comentarios.
Ya hemos configurado esto en el ejercicio, por lo que,
cuando el usuario publica el comentario,
nos hemos asegurado de verificar
la autenticidad del usuario y, a continuación, cuando se publique el comentario,
hemos configurado el ID de autor para el comentario utilizando el ID de usuario.
Por lo tanto, ya lo hemos completado.
Pero ahora, además,
para las operaciones de poner y eliminar en los comentarios,
solo el usuario que haya enviado el comentario específico
podrá hacer operaciones de poner y eliminar en sus propios comentarios.
Cualquier otro usuario no puede modificar los comentarios de otra persona.
Del mismo modo, incluso el administrador no puede modificar los comentarios de otra persona
ni eliminar los comentarios de otra persona.
Así que, esa es la segunda parte de esta tarea que vas a hacer.
La tercera parte es que un administrador puede consultar
el punto final /users y pedir la lista de usuarios registrados,
ningún otro usuario ordinario puede hacer esta consulta.
Así que, esta es la otra restricción que vamos a poner ahí.
Ahora, para verificar que un usuario es un administrador,
primero verificaremos que el usuario es un usuario registrado.
Por lo tanto, la función de verificación de usuario que ya hemos implementado en
authenticate.js debe aplicarse incluso donde necesite verificar el administrador.
Primero, comprueba que es un usuario verificado, a partir de
entonces, introducirá otra función llamada VerifyAdmin en el
archivo authenticate.js que comprobará para asegurarse de que el usuario es un administrador.
Ahora, para verificar si un usuario es un administrador,
todo lo que necesita hacer es verificar el rec.user que está en
el objeto de solicitud rec.user allí,
verifique si el indicador admin es verdadero o no.
Si el indicador admin es verdadero,
permitirá que el proceso normal de continuar con el [inaudible] suceda.
Si el usuario no es un administrador,
generará un error y devolverá un mensaje de error al lado del cliente.
Por lo tanto, así es como vamos a manejar la cuenta de usuarios administradores.
Ahora, cuando un usuario está tratando de modificar o eliminar sus propios comentarios,
tenemos que comprobar que el autor del comentario es el
mismo que el usuario que está tratando de modificar el comentario.
Ahora, el rec.user también tiene el campo ID,
por lo que debe cruzarlo con el campo autor del comentario.
Si estos dos coinciden,
entonces permitirá al usuario realizar las operaciones de poner o eliminar.
Si no coinciden,
entonces no permitirá las operaciones de poner o eliminar en ese comentario específico.
Así que este es el otro aspecto que vas
a implementar como parte de tu tercera tarea.
Veamos cómo funcionan todas estas cosas
mediante el uso de Postman para realizar varias operaciones en nuestro servidor.
Volviendo a Postman,
permítanme primero realizar una operación GET en
los platos para solo verificar qué hay en mi base de datos.
Por lo tanto, si realizo una operación GET en los platos,
observe que no estoy poniendo ninguna autenticación en el encabezado.
La operación GET está permitida por cualquiera.
Entonces, cuando realizo la operación GET,
puedo ver que ya tengo un plato con un comentario ya en su lugar en ese plato.
Este comentario ya fue publicado por este usuario.
Entonces, ya tenemos un plato en el sistema allí.
Entonces, esto está perfectamente bien,
voy a eliminar el plato.
Ahora, para eliminar el plato,
obviamente esa operación no puede ser realizada por un usuario ordinario.
Por lo tanto, déjame iniciar sesión como,
para que pueda ver que estoy iniciando sesión como un usuario normal.
Por lo tanto, permítanme iniciar sesión como usuario regular.
Entonces, cuando inicie sesión, obtendré el token.
Entonces, voy a copiar este token y guardarlo.
Ahora, que tengo mi token,
permítanme realizar una operación DELETE en los platos.
Entonces, cuando voy a la operación DELETE.
Entonces, déjame seleccionar este GET y luego hacer una operación DELETE con los platos.
En el encabezado, permítanme incluir la autorización aquí y notarían
que cuando pegamos en la solicitud y luego enviamos la autorización DELETE,
notarían que inmediatamente regresa con este mensaje aquí,
como se puede ver en la vista previa,
dice «Usted no está autorizado a realizar esta operación! «
Entonces el código de error está prohibido 403.
Por lo tanto, este es un mensaje que ha generado
la función VerifyAdmin que va a implementar como parte de este ejercicio.
Por lo tanto, si el usuario no es un administrador,
entonces este es el mensaje que su VerifyAdmin
generará y no permitirá que la solicitud vaya más allá de ese punto.
Por lo tanto, puede ver que he cerrado la operación DELETE.
Ahora, ¿cómo haces esto?
En su código, ha visto que para aplicar VerifyUser,
configuramos Authenticate.VerifyUser en las
operaciones POST, PUT y DELETE.
Ahora, puede encadenar el middleware uno tras otro.
Por lo tanto, podemos decir Authenticate.VerifyUser coma
y luego siguiente puede decir Authenticate.VerifyAdmin,
para aplicar el VerifyAdmin justo después del VerifyUser.
Por lo tanto, si desea que una operación se restrinja solo al administrador,
primero haga la parte VerifyUser y luego inmediatamente después de eso,
aplique el middleware VerifyAdmin.
Justo después de eso. Por lo tanto, si estas dos comprobaciones
, pasan con éxito, entonces pasará a realizar la operación.
Si se produce un error en la comprobación VerifyAdmin,
devolverá este mensaje de error como se ve
aquí y, a continuación, abortará la operación de esa parte.
Por lo tanto, devolverá el siguiente error de su VerifyAdmin,
si el usuario no es un administrador.
Por lo tanto, le he demostrado cómo va a
usar la cuenta de usuarios de administrador para restringir las operaciones de
PUT, POST y DELETE operaciones.
Lo mismo, las operaciones POST y PUT tampoco serán permitidas en cualquiera de estas n partes.
Ahora, permítanme demostrar el otro aspecto aquí.
Entonces, viste que allí,
cuando realizamos la operación GET,
viste que ya había un comentario que fue publicado por el nombre de usuario Jogesh,
el primer usuario que está en mi sistema.
Ahora, voy a iniciar sesión como el otro usuario.
Por lo tanto, iniciaré sesión como en mi segunda cuenta que es Muppala y luego cuando inicie sesión,
obtendré nuevamente el token.
Así que, déjame tomar este token aquí.
Déjame copiar este token.
Ahora, lo que voy a hacer es hacer un GET en los platos localhost.
Por lo tanto, déjame hacer un GET en los platos localhost para mostrarte el comentario específico dentro de aquí.
Por lo tanto, este comentario en particular con este ID.
Así que, lo que voy a hacer es
copiar esa identificación del plato.
También voy a copiar el ID de comentario desde aquí y voy a realizar
una operación DELETE en este plato específico
y recordar que tenemos
la barra diagonal de comentarios y luego este ID de comentario en particular.
Ahora, recuerde que este comentario fue publicado por este nombre de usuario,
pero ahora he iniciado sesión como el otro usuario con un nombre de usuario diferente.
Entonces, cuando ahora realizo la operación DELETE usando la otra cuenta,
inmediatamente notarías que aquí dice:
«¡No estás autorizado a eliminar este comentario! «
Entonces dice 403, lo mismo.
Si intenta realizar una operación PUT en ese comentario específico iniciado como otro usuario
, dirá: «¡No está autorizado a actualizar este comentario!»
Por lo tanto, tanto PUT, DELETE como UPDATE del comentario de otra persona no están permitidos.
Así que ahora, déjame iniciar sesión como administrador en este punto y luego déjame tratar de eliminar
ese comentario en particular y verías que se generará el mismo mensaje.
Por lo tanto, un administrador tampoco puede eliminar o actualizar los comentarios de otra persona.
Por lo tanto, para iniciar sesión como administrador,
déjame entrar en la POST aquí y luego déjame iniciar sesión como administrador.
Ahora, recuerde que estos tokens serán válidos durante 33.600 segundos.
Por lo tanto, puede guardar estos tres tokens que genera para los tres usuarios.
Por lo tanto, no es necesario seguir iniciando sesión como ese usuario en particular.
Siempre y cuando use el token correcto en el encabezado,
sus operaciones funcionarán bien identificando a los tres usuarios diferentes.
Por lo tanto, déjame iniciar sesión como administrador aquí.
Entonces, cuando inicio sesión como administrador,
obtengo el token aquí.
Entonces, voy a copiar y guardar este token.
Solo recuerde qué token pertenece a quién cuando haga una copia de esto.
Ahora, volviendo a esto, eliminar la operación de comentario.
Voy a entrar en el encabezado y luego voy a cambiar esto al token para
el administrador y luego tratar de realizar la misma operación DELETE y luego ves
que incluso el administrador no está autorizado para eliminar el comentario publicado por otro usuario.
Esto es perfectamente aceptable.
Pero tratemos de eliminar el mismo comentario,
por este usuario que creó
ese comentario y verías que eso se puede hacer con éxito.
Entonces, vamos a realizar esa operación.
Entonces, para hacer eso, volveré y buscaré el token que
tengo para el primer usuario y luego cambiaré el campo Autorización.
Ahora, para esta operación DELETE,
voy a cambiar esto a portador,
y luego este es el token para el primer usuario con el nombre de usuario Jogesh.
Por lo tanto, cuando intente eliminar ese comentario,
notará que el comentario ahora se elimina con éxito.
Por lo tanto, como puede ver en los pasos,
el comentario solo puede ser eliminado por el usuario que creó ese comentario.
Ahora, el siguiente paso,
cuando hacemos la operación DELETE en los platos,
vimos anteriormente que si realizamos la operación DELETE como un usuario común,
aparece un mensaje que dice:
«¡No está autorizado para realizar esta operación!»
Por lo tanto, voy a cambiar este token al token del administrador y luego
le mostraré que un administrador puede realizar la operación DELETE en los platos y la olla.
Entonces, al entrar en esta solicitud,
permítanme cambiar el token para que sea el token para el usuario administrador.
Por lo tanto, cuando realice la operación DELETE como usuario administrador,
notará que la operación DELETE es
exitosa y luego responderá con el mensaje aquí.
Ahora, cuando hago un GET en el extremo de los platos,
se dará cuenta de que las operaciones GET muestran que mis platos se han vaciado.
Ahora, la otra operación que también implementará en esta asignación,
es que podemos hacer una operación GET en el extremo de los usuarios de barra diagonal.
Por lo tanto, cuando realice una operación GET en el extremo de usuarios de barra diagonal,
notará que si no
es un usuario autorizado, dirá que no está autorizado para realizar esta operación.
Por lo tanto, el localhost: 3000/users/endpoint,
ahora va a permitir que esto sea realizado solo por el administrador.
Por lo tanto, si un usuario común,
si inicia sesión como un usuario común con el encabezado,
no se le permitirá realizar esta operación.
Ahora, permítanme cambiar este token por
el token fuera del administrador y luego verá que
el administrador podrá realizar esta operación.
Entonces, yendo a GET,
permítanme cambiar este token al token para
el usuario administrador y luego cuando realice la operación GET en eso, regresa.
Como puede ver, los tres usuarios que están registrados en mi sistema,
muestra el usuario número uno, el
usuario número dos y el usuario número tres.
Por supuesto, observe que el hash y la sal se eliminan,
cuando el mensaje es devuelto por el lado del servidor al lado del cliente.
Por lo tanto, la información de hash y sal nunca se revelará fuera.
Por lo tanto, Mongos se encargará automáticamente de
filtrar esa información antes de enviar de vuelta la información del usuario.
Entonces, porque no deberías estar revelando la
información de hachís y sal al mundo exterior.
Por lo tanto, esta es la información de tres cuentas de usuario que se devuelve.
Por lo tanto, esto sólo se devuelve si realiza la operación GET en
el extremo de usuarios de barra diagonal como el usuario administrador.
Si realiza la misma solicitud que cualquier otro usuario,
esto no estará permitido.
Por lo tanto, nuevamente
verificará primero, verifyUser y luego verificará VerifyAdmin y solo si es un administrador,
entonces esta operación se puede realizar en este punto final.
Por lo tanto, estas son todas las diversas tareas que hará como parte de esta asignación.
Los detalles de cómo deben hacerse se documentan en las instrucciones de asignación.
Por lo tanto, lea las instrucciones antes de proceder a completar la tercera asignación.
Diviértete completando la tercera tarea.