‫-: Bienvenido de nuevo.
‫Entonces, hemos implementado la autenticación
‫en nuestro proyecto hasta este momento.
‫Y funciona bien.
‫Sin embargo, a veces, simplemente autenticarse, por lo
‫tanto, iniciar sesión como usuario,
‫no es suficiente.
‫Y, entonces,
‫en este video, también implementaremos la autorización.
‫Entonces, imagine el acto de eliminar un recorrido de
‫nuestra base de datos.
‫Por lo tanto, no todos los usuarios deberían,
‫por supuesto, poder hacer eso.
‫Incluso si el usuario está conectado, ¿verdad?
‫Entonces, básicamente necesitamos autorizar solo a
‫ciertos tipos de usuarios para
‫realizar ciertas acciones.
‫Y eso es exactamente lo que es la autorización.
‫Se trata de verificar si un determinado usuario tiene
‫los derechos para interactuar con un determinado recurso.
‫Entonces, nuevamente, con autorización, básicamente verificamos si
‫un determinado usuario puede acceder a un determinado recurso, incluso
‫si está conectado.
‫Entonces, no todos los usuarios que hayan iniciado sesión podrán realizar
‫las mismas acciones en nuestra API, ¿de acuerdo?
‫Y este es un escenario muy común que
‫debería implementarse en todas y cada una de
‫las aplicaciones web normalmente, ¿de acuerdo?
‫Así que vamos a construir aquí otra
‫función de middleware, esta vez para restringir ciertas rutas.
‫Por ejemplo, para eliminar recorridos.
‫Entonces, esto significa que vamos a construir otra
‫función de middleware aquí.
‫Esta vez, para restringir ciertas rutas, como,
‫por ejemplo, eliminar recorridos,
‫solo a ciertos roles de usuario.
‫¿Okey?
‫Así que déjame mostrarte cómo se vería
‫eso en la práctica.
‫Entonces, aquí, en las
‫rutas de los recorridos, volvamos a ese ejemplo de eliminación
‫de recorridos, y agreguemos algo de middleware a la pila aquí.
‫Así que authController, protege.
‫Entonces, primero, siempre debemos
‫verificar si un usuario está realmente conectado, ¿de acuerdo?
‫Entonces, si un administrador está tratando de eliminar un
‫recorrido, aún deberá
‫verificar si realmente ha iniciado sesión, ¿verdad?
‫Entonces, el primer middleware de la pila
‫aquí siempre será el de protección.
‫Pero luego, después de ese,
‫también tendremos el authController. restringir.
‫Así que restringe, ¿de acuerdo?
‫Y en esta función pasaremos algunos roles de usuario,
‫que estarán autorizados a interactuar con este recurso.
‫En este caso, con la eliminación de un recorrido, ¿de acuerdo?
‫Así que establezcamos este en admin.
‫Entonces, solo para administradores.
‫Bien, y ahora estamos tratando con roles de usuario aquí.
‫Así que como admin.
‫Y ahora mismo, no tenemos eso en nuestro modelo de usuario.
‫Así que implementemos eso rápidamente aquí.
‫Está bien.
‫Entonces, hagámoslo.
‫En realidad, antes de las contraseñas, como aquí.
‫Y aquí abajo puede ver cómo nuestro controlador de excepciones
‫no detectado está funcionando bien,
‫porque restrictTo aún no es una función, ¿verdad?
‫Aún no lo implementamos.
‫Simplemente lo usé para mostrar qué es exactamente
‫lo que vamos a construir.
‫Y, por supuesto, hay un
‫error, por lo
‫que nodemon ahora está esperando a que reiniciemos el servidor, ¿de acuerdo?
‫De todos modos, el rol aquí debería ser
‫del tipo String, y ahora voy a usar el validador de enumeración para
‫permitir que solo se especifiquen ciertos tipos de roles aquí.
‫Y estos son los usuarios generales, por lo que los normales, así
‫que llamémoslos usuario.
‫Luego, tenemos el guía
‫turístico, tenemos el guía turístico
‫principal y tenemos el administrador.
‫Entonces, solo llamo a ese administrador, ¿de acuerdo?
‫Y estos roles de usuario que tenemos aquí, por
‫supuesto, serán específicos del dominio de la aplicación.
‫Entonces, por ejemplo, cuando está ejecutando un sitio comunitario,
‫no tendrá mucho sentido
‫tener una guía y una guía principal.
‫En su lugar, probablemente
‫tendrá, como moderadores, colaboradores o miembros.
‫Por lo tanto, siempre tendrá diferentes
‫nombres, según el tipo de aplicación que esté escribiendo.
‫Pero en nuestro caso, esto es lo que tiene sentido.
‫Luego, también queremos establecer un valor predeterminado aquí, por
‫lo que en realidad no tenemos que
‫especificar siempre qué tipo de usuario estamos creando.
‫Y entonces usuario, el usuario normal, digamos, es
‫el que se creará por defecto.
‫Así que ahora vayamos
‫a eliminar los usuarios que ya
‫tenemos, porque no
‫tienen ningún rol, por lo que ya no los necesitamos así.
‫Está bien.
‫Entonces, en realidad,
‫sigamos adelante y creemos algunos nuevos.
‫Entonces, me voy a registrar aquí como hola
‫@ jonas, y ahora será un usuario normal, y ahora no pudimos obtener
‫ninguna respuesta, y eso
‫es, por supuesto, porque tenemos este error aquí,
‫así que, vamos a saque rápidamente esta línea de código.
‫Y ahora el error se ha ido.
‫Y ahora debería ejecutarse,
‫y de hecho ahora tenemos este
‫usuario, con el rol de usuario, ¿de acuerdo?
‫Así que ese es
‫nuestro valor predeterminado, pero ahora creemos un administrador aquí.
‫Y para dejar eso
‫realmente claro, pongámoslo aquí en el correo electrónico
‫también, y ahora tenemos que especificar realmente el
‫rol y configurarlo como administrador.
‫Envíe eso, y ahora llegamos a nuestro administrador del sistema.
‫Frio.
‫Entonces, volvamos aquí, en realidad volvamos a poner este código, y
‫ahora lo haremos para que
‫podamos pasar múltiples argumentos a este restrictTo.
‫Entonces, quiero que el administrador pueda eliminar recorridos, pero
‫también eliminar una guía.
‫¿Está bien?
‫Y agreguemos eso aquí también.
‫¿Okey?
‫Por lo tanto, el administrador y la guía principal ahora
‫pueden eliminar recorridos, pero no las guías normales y tampoco los usuarios normales.
‫¿Está bien?
‫Así es como va a funcionar restrictTo,
‫ahora vamos a implementarlo.
‫Entonces exporta. restrictTo, y
‫ahora, ¿cómo vamos a implementar esto?
‫Porque normalmente, no podemos pasar
‫argumentos a una función de middleware, ¿verdad?
‫Pero en este caso, realmente queremos hacerlo.
‫Queremos pasar los
‫roles, ¿quiénes tienen permiso para acceder al recurso, verdad?
‫Entonces, este caso, el administrador y la guía principal.
‫Por lo tanto, necesitamos una forma de pasar argumentos básicamente
‫a la función de middleware de una
‫manera que generalmente no funciona.
‫Entonces, ¿cómo vamos a hacer eso?
‫Bueno, aquí, en realidad crearemos como una
‫función contenedora, que luego devolverá la
‫función de middleware que realmente queremos crear, ¿de acuerdo?
‫Entonces, esta es la función restrictTo, y
‫aquí queremos pasar
‫un número arbitrario de argumentos.
‫Entonces, básicamente, de roles.
‫Y entonces podemos usar la sintaxis del parámetro
‫rest, que nuevamente es nueva en ES6, y esto
‫luego creará una
‫matriz de todos los argumentos que se especificaron, ¿de acuerdo?
‫Así que estamos creando
‫esta función y de inmediato devolveremos una nueva función.
‫Y esta es la función del middleware en sí.
‫Entonces, solicitud, respuesta y siguiente.
‫¿Okey?
‫¿Tener sentido?
‫Entonces, esta función aquí
‫básicamente tendrá acceso al parámetro de
‫este rol aquí, porque hay un cierre, ¿de acuerdo?
‫Entonces, como un comentario aquí para explicar,
‫los roles son una matriz.
‫Entonces, por ejemplo, podría ser,
‫en este caso, administrador y guía principal, ¿de acuerdo?
‫Entonces, ¿cuándo le daremos acceso a un usuario a una ruta determinada?
‫Bueno, básicamente, cuando su rol de
‫usuario está dentro de esta matriz de roles que pasamos, ¿verdad?
‫Digamos que ahora tenemos el usuario
‫normal, que tiene un rol de usuario simple, así
‫que escribámoslo aquí.
‫El rol ahora es solo usuario.
‫Entonces, básicamente, no está contenido en esta matriz
‫y, por lo tanto, ese usuario no tiene permiso, ¿de acuerdo?
‫Y entonces, escribamos eso en código.
‫De hecho, es bastante simple.
‫Entonces, si no roles. incluye, y está bien, una vez
‫más, incluye es un método de matriz muy agradable
‫que está en Java Script disponible en todas las matrices, ¿de acuerdo?
‫Entonces, si esta matriz de roles no
‫incluye el rol del usuario
‫actual, entonces no le damos permiso a ese usuario.
‫¿Y dónde se almacena el rol del usuario actual?
‫Bueno, recordemos la línea de código que
‫pusimos aquí, justo al final donde
‫otorgamos acceso a la ruta protegida,
‫almacenamos el
‫usuario actual en la solicitud. usuario.
‫Y recuerde cómo este middleware
‫de protección siempre se ejecuta antes de restrictTo, ¿verdad?
‫Entonces, aquí, primero tenemos proteger
‫y luego restringir.
‫Y para cuando se ejecuta esta función de middleware aquí,
‫esta ya se ha completado y
‫ha puesto al usuario actual en el objeto de solicitud.
‫Y ahora, podemos usar eso aquí.
‫Así que solicítalo. usuario. papel.
‫Entonces ahí es donde se almacena el rol.
‫Tan sencillo.
‫En este caso, creamos un nuevo error.
‫Así que como antes, y
‫ahora decimos que no tienes permiso para realizar esta acción.
‫Y ahora un nuevo código de estado, que es 403.
‫Y este significa prohibido, ¿de acuerdo?
‫Entonces, realmente hay
‫un código de estado http específico solo para
‫este caso, así que básicamente para la autorización, ¿de acuerdo?
‫Y, bueno, de lo contrario, simplemente llamamos a next.
‫Y eso es realmente.
‫Así que eso es tan simple como es.
‫Así que recapitulemos rápidamente lo que acabamos de hacer aquí.
‫Entonces, aquí, primero ejecutamos el middleware de protección.
‫Luego, restringeTo middleware,
‫y solo si estos dos middlewares pasan al
‫siguiente, pasamos al recorrido principal.
‫Básicamente, este controlador de
‫ruta, o este controlador de ruta, está
‫protegido y también está restringido por este
‫middleware que acabamos de crear.
‫Luego, en
‫esta función, pasamos todos
‫los roles que pueden interactuar con este recurso.
‫Entonces, básicamente, ¿cuáles están autorizados
‫a ejecutar esta función de controlador, de acuerdo?
‫Entonces, esta función restrictTo se ejecutará y
‫devolverá la función de middleware en sí, ¿de acuerdo?
‫Y esa función de middleware en sí es en realidad esta.
‫Entonces, debido al
‫cierre, tendrá acceso a roles, ¿de acuerdo?
‫Y entonces, digamos que el rol del usuario actual, que
‫es, recuerde, almacenado en req. usuario. papel, ¿verdad?
‫Entonces, digamos que su rol es usuario, y
‫dado que ese rol no está en la matriz
‫de este rol, entonces obtenemos este error, ¿de acuerdo?
‫Y eso es lo que este papel. incluye pruebas aquí para, ¿de acuerdo?
‫Pero, por supuesto, si
‫está incluido, pasamos al siguiente middleware.
‫Que de nuevo, es el propio controlador de ruta.
‫Frio.
‫Entonces, espero que tenga sentido.
‫Ahora sigamos adelante y probémoslo rápidamente.
‫¿Okey?
‫Entonces, ahora mismo,
‫tenemos este token aquí, almacenado en la variable JTW, ¿verdad?
‫Así que recuerda eso de la última conferencia.
‫Entonces, estamos en este entorno
‫de desarrollo, y aquí está esa variable.
‫Así que exactamente el que está aquí abajo.
‫¿Está bien?
‫Entonces, si ahora elimináramos
‫un recorrido, tendríamos que especificar esa variable allí, ¿verdad?
‫Así que vayamos a la autorización, el token
‫de portador, y luego
‫ya lo pone aquí para nosotros.
‫Entonces ya sabe
‫que este es el que queremos usar,
‫porque, bueno, lo usamos antes, ¿vale?
‫Ahora, quiero comenzar mostrándole que un
‫usuario normal no puede eliminar un recorrido ahora, ¿de acuerdo?
‫Entonces, comencemos iniciando sesión como un usuario regular.
‫Y eso es hola, ¿verdad?
‫Recuerda, ahora mismo tenemos hola @ jonas. io, que es un usuario normal, y
‫tenemos admin @ jonas. io.
‫Y todavía tenemos este viejo aquí, eliminémoslo.
‫Está bien.
‫Y entonces empezaré con hola @ jonas. io.
‫¿Okey?
‫Entonces, al iniciar sesión, ese token se almacenará en la variable
‫de entorno, y ahora estamos listos
‫para eliminar un recorrido.
‫De hecho, también necesitamos obtener una identificación ahora, así
‫que obtengamos una rápidamente desde aquí, así
‫que básicamente vamos a eliminar uno de nuestros recorridos aquí.
‫Así que usemos el último aquí.
‫Entonces, el Stargazer.
‫¿Okey?
‫Y veamos si recibimos nuestro mensaje de error.
‫Y, de hecho, no tiene permiso para
‫realizar esta acción.
‫Entonces, 403.
‫Entonces, de hecho, está funcionando, ¿verdad?
‫Pero, para completar
‫esto ahora, por supuesto, inicie sesión como administrador.
‫Entonces, admin.
‫Acceso.
‫Y entonces este token ahora se almacena en esta variable.
‫Entonces, si ejecuta
‫esto ahora, deberíamos poder eliminar el recorrido de manera efectiva.
‫¿Quiero ver?
‫Y se ha ido.
‫Entonces tenemos un código 204, sin contenido, que
‫es el estándar al eliminar, pero
‫ahora, si obtenemos todos nuestros recorridos,
‫deberíamos ver un número ocho aquí, por lo
‫que solo ocho
‫resultados, y eso significa que el último es ahora ido, ¿de acuerdo?
‫Y ahora mismo, como acabamos de
‫demostrar, un administrador tiene
‫permiso para eliminar recorridos de forma efectiva, ¿de acuerdo?
‫Y, realmente no puedo enfatizar lo
‫suficiente lo importante que es este fragmento de código aquí.
‫Entonces, básicamente, de dónde obtuvimos el rol del
‫usuario actual del middleware antes, ¿de acuerdo?
‫Entonces, almacenar al usuario en la solicitud como lo
‫hicimos aquí, es realmente
‫crucial para que este próximo paso realmente funcione, ¿de acuerdo?
‫Entonces, la ID que está codificada en el token web de Jason es lo
‫que hace que nuestro código sepa si el
‫usuario que está tratando de realizar la acción es un usuario, si es un
‫administrador, o si es una guía de clientes potenciales, o lo que sea.
‫Nuevamente, porque esos
‫datos provienen de este middleware de protección.
‫Excelente.
‫Esta fue otra pieza importante del rompecabezas en
‫la implementación de nuestro flujo de trabajo de autenticación aquí.
‫Y, por supuesto, desea restringir muchas
‫otras rutas, por ejemplo, actualizar aquí, ¿de acuerdo?
‫Pero lo dejaré para un
‫punto posterior del curso, ¿de acuerdo?
‫Aquí mismo, solo quería mostrarte
‫cómo funciona todo esto, ¿de acuerdo?
‫Entonces, creo que lo hice con éxito.
‫Espero que haya entendido cómo funcionó esto y, por supuesto,
‫si no es así, siempre puede hacer una pregunta en
‫la sección oficial de preguntas y respuestas.
‫De todos modos, hay más contenido excelente en este momento,
‫así que sigamos adelante.