¿Cómo se implementa la verificación de permisos en autenticación?
En el proceso de desarrollo de aplicaciones, la seguridad es un pilar fundamental. En este contexto, la verificación de permisos de usuario se convierte en una tarea crucial. En esta clase, abordamos la implementación final de la verificación de autenticación y permisos utilizando un token para garantizar que solo los usuarios autorizados puedan realizar ciertas acciones.
¿Cómo se configura la función de autenticación?
Para verificar la autenticación, primero configuramos una función que nos permitirá comprobar si un usuario tiene permiso para realizar una acción específica dentro de la aplicación. La implementación se realiza a través del módulo de autenticación, del cual exportamos varias funciones clave.
Aquí están los pasos básicos a seguir:
Añadir la función de comprobación: Inicialmente, se incorpora una función que verifica el permiso de un usuario por medio de su ID.
Importar el módulo: Asegúrese de importar apropiadamente el módulo de autenticación en la estructura del proyecto, para acceder a las funciones necesarias.
Implementación de la comprobación:
Establecer el token del usuario y verificar sus permisos.
Ejecutar la acción si el ID del usuario autenticado coincide con el ID necesario para la acción.
En caso contrario, lanzar un error indicando que no tiene permisos.
if(user.id=== action.id){// Acción permitida}else{thrownewError("No puedes hacer esto");}
¿Cómo se manejan errores en autenticación?
Durante la autenticación y la verificación de permisos, podemos encontrarnos con varios errores comunes que deben ser manejados apropiadamente. Aquí te enseñamos cómo:
Token faltante: Si al realizar una autenticación no se dispone de un token, la aplicación fallará en la verificación. En este caso, se debe generar un token mediante el proceso de inicio de sesión (login).
Manejo de excepciones: Lanzar mensajes de error claros y precisos si el usuario intenta realizar una acción sin los permisos necesarios.
thrownewError("No puedes editar esto porque no tienes los permisos adecuados.");
¿Cómo se efectúa una verificación de token en la práctica?
Para poner en práctica la verificación, sigamos un ejemplo:
Realizar login: Cuando un usuario, como "Paco", inicia sesión, se le genera un token que debe ser utilizado para todas las solicitudes subsecuentes.
Verificación del token en acciones protegidas: Antes de ejecutar una acción, comprueba que el token del usuario es válido y garantiza que el ID del token coincide con el ID necesario para la acción.
Lista de permisos:
Si el token es válido y tiene los permisos necesarios, permite la acción.
Si no, devuelve un error indicando la falta de permisos.
Conclusión
La implementación de un sistema de autenticación robusto no solo es crucial para la seguridad de la aplicación, sino también para garantizar que los datos y acciones estén protegidos adecuadamente bajo las credenciales correctas. Anima a los estudiantes a profundizar más en mecanismos de seguridad para seguir avanzando en el desarrollo de sus aplicaciones de manera segura y eficiente.
Estos conocimientos son esenciales para cualquier desarrollador que aspire a construir aplicaciones escalables y seguras. Continúa con este excelente trabajo y sigue aprendiendo sobre el maravilloso mundo de la seguridad informática aplicada al desarrollo de software.
En el replace de Bearer se esta haciendo como replace("Bearer", "") pero por defecto cuando se manda un token con este formato, por defecto se le agrega un espacio en el medio. Digamos que tu token es "qwerty12345" al servidor va a llegar como "Bearer qwerty12345" por ende para obtener correctamente el token y que no explote tenemos que hacer un replace con Bearer y un espacio, osea replace("Bearer ", "").
A este punto cuando hagan el update les va a crear un usuario nuevo. Esto esta bien por que en el metodo upsert definido en nuestro dummy simpletemente hacemos un push sobre nuestra tabla, no hacemos primero una buesqueda por id si el mismo nos viene y actualizamos o en caso contrario creamos un nuevo "record". Esto seguro va a estar resuelto cuando se use un store en si mismo pero si quieren arreglarlo por ahora pueden agregar un metodo de busqueda por id dentro de la tabla aunque como tip deberia la tabla en vez de ser un array ser un hash, donde cada key es un id, asi la busqueda se hace mas optima.
Les puede pasar que algunas exceptions que les salgan, lleguen hasta el cliente en la response, keep calm and watch the next class.
Cualquier cosa estoy para dar una mano si tienen algun problema
Gracias!
Excelente aporte! Gracias
Importante: jwt.verify si los tokens son diferentes te devuelve una exception. Para que no se rompa podes wrappear verify con un try-catch
Segun como venimos en este curso esto no es necesario ya que la promesa del upsert tiene un catch donde se captura este error y lo devuelve con un codigo 500
a mi me agrega otro Usuario , porfavor actualizar esta sección
a mi tambien. lograste resolverlo?
Me encontré con un error super extraño. Usando el mismo token siempre me devolvía error jwt.verify.
Hice console.log del token generado contra el token que recibo, exactamente los mismos.
Si llegas hasta acá y tuviste ese error, yo lo resolví usando TRIM dentro de la function getToken
Verificá el replace, estás usando "Bearer" y debería
ser "Bearer " ( con un espacio), ya que en el encabezado se envía un string como este
"Bearer xxxxxxx", lo que los interesa es lo de xxxx (sin el espacio separador).
Trim lo que hace es sacar espacio excedente.
Gran aporte! me ayudo a resolver mi Error
ami me crea otro usuario
Estuve probando y cuando vuelves a iniciar sesión te da un nuevo token pero tu puedes seguir usando los ++tokens antiguos++ para editar tu usuario, hay una manera practica de evitar esto?
agregando un time más algunos milisegundos a la generación del token con jwt para que expire:
jwt.sign( data,exp:moment().add(5,'m').unix())
Alguien sabe como solucionar cuando el signature del web token es invalido?
muy buena clase en la anterior no habia entendido nada y en esta se aclaro todo!!
Por el momento no responde nuestro servidor al editar nuestro usuario, ésto porque nunca llega a un response.success, para ésto tenemos que devolver algo en el check, por ejemplo:
const check ={own:(req, owner)=>{const decoded =decodeHeader(req)if(decoded.id!== owner)throwerror('no puedes hacer ésto',401)return(true)}}
Este profesor es uno de los mejores de Platzi según mi punto de vista.
Pero esta clase me mareó.
La tuve que ver mas de 4 veces y prestando suma atención a los detalles, porque la verdad es que está super confuso todo.
es porque precisamente el profesor no es tan bueno
Muy buena clase, aunque tuve que verla 5 veces e incluso volver a ver las clases anteriores para entender lo que estaba haciendo el profesor y debuggear los errorres de mi código.
Si están usando try/catchs y arrow functions, en el network.js de user tienen que llamar al middleware de la siguiente manera:
Me arroja un error que secure.checkAuth no es una función u.u
No se tocó como hacer logout. ¿Existe algo como destruir el token?
Para hacer el logout tendrias que borrar el Bearer token y manejarlo como que el usuario tiene que volver a ingresas sus credenciales. (Esa sería mi teoría)
Tengo una duda y es que en postman no me aparece el resultado que aparece al profesor, pero si me aparece en wsl , como hago para que se vea reflejado este dato en postman
En postman es un pelín diferente, aquí los pasos:
Añado usuario
Hago el login y tomo el token
Voy a editar usuario
authorization > bearer token
pegar el token
luego en el body pegar el id que me creo en consola
Hasta ahora me di cuenta que tenia problemas en nanoid
// Esto crea problemas de "nanoid is not a function"const nanoid =require('nanoid')// Lo que deben hacer es esto: const{ nanoid }=require('nanoid')// Ya que nanoid dentro de la dependencia si es una funcion
<code>
```
¿El error "No puedes hacer esto", no debería devolverse como un error estandarizado de los definidos previamente en el response?
jajaja ok, tranquilos, esto se resuelve en la próxima clase :)
Esta parte del manejo de los token de jwt y la validación del id que envía el usuario es para validar que el usuario haya iniciado sesión correctamente?, si es así podemos manejar un campo con un nombre diferente a "id" para identificar quien es el que quiere hacer dicha acción?
la idea es que el usuario que inició sesión pueda editar sólo su propia data y no la de alguien más.
¿Cuál es la diferencia entre usar un Bearer token y enviar el token en el header?
¿Es buena practica agregar infirmación sensible en los tokens?
Hola, Gerardo.
Eso no es lo recomendable, debido a que ese token puede ser parseado para ver los datos
Este video del curso me pareció algo confuso, en concordancia con lo que dicen los compañeros. Para los que preguntan que el usuario se está duplicando, efectivamente se está duplicando, incluso se ve al final del código del profe que el usuario se duplicó. En lo personal no valdría la pena arreglar eso porque en dos capitulos más se conectará la aplicación con una base de datos real y ya no usaremos el archivo dummy.js.
