@@luisalfredoricopabardales6345 Por poder, lo podría hacer algún día. Pero la única diferencia en el funcionamiento de canMatch con respecto al resto de guardas, es que devolviendo false desde canMatch, en vez de detener la navegación, lo que hace es que se ignore esa ruta y pase a la siguiente. Lo que te permitiría por ejemplo tener más de una ruta con un mismo path. un saludo y gracias por tu comentario 😉
ufffffffffffffff excelente, muchas gracias, la manera en que explican es increíble, enserio muchas gracias, la manera en que se comprende la información, de la forma que la explican ufff, contenido de calidad dijeron por ahí en otro comentario. Muchas Gracias.
Excelente contenidoo! Muy claro y conciso. Gracias por tu tiempo, trabajo y esfuerzo, de lo mejor que he encontrado en youtube !! nuevamente mil gracias! Quedo atento a más contenido !! Saludos !
Tremendos videos, descubri tu canal hoy mismo y tenes las respuesta a muchas preguntas que me he hecho. Sin duda me ayudarán a llevar mi nivel de angular a otro nivel. Me gustaria ver un video haciendo un proyecto para ver cómo los piensas y como encara un proyecto entero alguien con tu expertise. Muchas gracias :D
Muchas gracias por tus palabras. Me apunto lo de crear un video sobre un proyecto completo para el futuro. Tienes alguna preferencia en cuanto al tipo de app que te gustaría ver? un saludo
Muchas gracias por compartir tu conocimiento, has logrado que entienda lo que estuve buscando por días!! De casualidad vendes cursos en alguna plataforma? De ser así sería genial que puedas compartir los links. De no ser el caso te invito a que crees dichos cursos, tu forma de enseñar es muy buena. Saludos desde Perú
Muchas gracias por el video, super entendible todo, solo tengo una duda, veo que la lógica de validación de los roles en la directiva lo haces en el pipe TAP, hay alguna diferencia de realizar la validación en el subscribe?, gracias de antemano
Hola Mario, la validación la hago en el map. En el tap simplemente renderizo o elimino el template de la app en función del resultado de la validación. Y sí, en este caso es indistinto definir esta lógica de renderizado en el tap o en el subscribe. un saludo y gracias por tu comentario
Excelente video cubre la mayoría de temas acerca de la seguridad,pero tengo una duda bro, para una aplicación que tiene más roles como seria una buena forma de tener esos roles y no ponerlos directamente en el html o en los app routing??
Sin saber el caso concreto, la cantidad de roles y como están relacionados entre si es difícil decirte. Si es un jerarquía directa de roles puedes optar por una guarda del tipo *hasMinimumRole(X)* , para no tener que añadir todos. Pero por ejemplo si tienes realmente muchos roles independientes entre si pero que comparten muchos permisos, pues quizás sería mejor solución asignar a las rutas y las acciones permisos en vez de roles y luego crear un servicio que chequee si el rol del usuario tiene ese permiso. un saludo y gracias por tu comentario 😉
interesante el video, tengo una consulta, si los roles los tengo en una base de datos y este lo obtengo mediante una api, cómo puedo implementarlo sin necesidad de colocar los roles en el código, solo necesito que me obtenga los roles de la base de datos?
Sin ver la implementación específica es difícil darte una respuesta concreta. Pero si no quieres hardcodear los roles en el código necesitarás crear algún tipo de diccionario con esos datos que obtengas de la bd del tipo {[accion/seccion]: rolesPermitidos[] } para poder validar si el rol del usuario le permite acceder a dicha sección o realizar una acción específica. un saludo y gracias por tu comentario
Excelente video, tengo una duda ahora con las functional guards "export const authGuard: CanActivateFn = (route, state) => {}", como podría recibir los roles en los parámetros pero sin perder route ni state. canActivate: [authGuard('admin')] ?
Sería igual que la guarda funcional hasRoles que hacemos en el video (13:35), pero definiendo en esa función interna los parámetros. En este caso en el video no los hemos añadido simplemente porque no los estábamos usando. Te quedaría algo así: function authGuard(roles) : CanDeactivateFn { return (route, state) => {} } o const authGuard = (roles): CanDeactivateFn => (route, state) => {} un saludo y gracias por tu comentario 😉
Muchas gracias por tu video. Tengo una pregunta, cuando se hace la redirección en el guard, ¿Cuál es la diferencia entre usar navigateByUrl y createUrlTree? Nunca había escuchado de este último, siempre lo hago con navigateByUrl.
Hola Nelson! Los dos métodos tienen dos propósitos diferentes: - navigateByUrl sirve para iniciar manualmente una nueva navegación. - y createUrlTree simplemente crea un objeto UrlTree para una ruta determinada. (Objeto que estamos devolviendo desde la guarda, trasladando así al Router la responsabilidad de aplicar la redirección) Para el 99% de los casos el resultado final de usar uno u otro en una guarda es prácticamente idéntico. Es más las guardas en las primeras versiones solo podían devolver un booleano y si querías hacer una redirección la tenias que hacer iniciando manualmente la navegación. un saludo
hola excelente explicación como podría implementar el inject del Router aparte del authService para redirigir a otra pagina al usuario en caso de no tener los roles correspondientes estoy teniendo problemas con eso
Solo tienes que añadir otro inject antes de devolver el observable desde la función interna y usar este para en el caso false devolver el UrlTree de la nueva ruta a la que quieras redireccionar, de forma similar a como hacemos en la guarda del login. La guarda para redireccionar en el ejemplo de video al dashboard en caso de que no tenga el rol quedaría así: export function hasRole(allowedRoles: Role[]) { return () => { const router = inject(Router); // Boolean(user && allowedRoles.includes(user.role)) || router.createUrlTree(['/dashboard']) //
Ambos tipos de guardas tienen un propósito distinto. El propósito de canLoad es prevenir la descarga de un módulo lazy asociado a una ruta si el usuario no tiene la autorización pertinente; y el de canActivate es prevenir la renderización de cierto componente. Si solo usas canActivate, un usuario llamémosle normal, no va a notar una diferencia notable. El único problema que puedes tener, es que todos los módulos lazy se van a descargar siempre que un usuario acceda a esas rutas asociadas, tenga o no permiso para ello. Esto conlleva que el código fuente de dichos módulos estará disponible desde ese momento en el navegador, y algún usuario curioso podría obtener alguna información relativamente sensible que tengas _hard-coded_ en los elementos de dicho módulo. un saludo y gracias por tu comentario.
Tengo una pregunta, si todas las guardas y roles se maneja del lado del cliente, eso no podria ser modificado desde las devtools y acceder a las vistas protegidas sin tener el rol solicitado? Solo he hecho manejo de roles y autorización en el backend
Por supuesto, como digo al principio del video, RBAC en el frontend lo tenemos que considerar más como un tema de UX que de seguridad. Porque aunque pueda servir para restringir el acceso a los usuarios digamos normales, cualquier usuario con un poco de conocimiento en la materia puede sobrepasarlo relativamente fácil. El RBAC del backend tiene que existir siempre y es el realmente importante. Esto es algo que he intentado recalcar en el video en el minuto 2:10 donde aunque un usuario no identificado pueda acceder a los pedidos, el listado de los mismos no se descarga porque la petición http devuelve error. A lo mejor tenia que haber sido más explicito. Un saludo y gracias por tu comentario 😉!
En el repositorio de este mismo proyecto tienes un ejemplo de cómo puede conseguirlo. Si vas al archivo del AuthService, verás que en cuando hacemos un login satisfactorio guardamos el token recibido en el localstore del navegador. Y para volver a cargar ese token guardado cuando se refresque la pagina, recuperamos este desde el constructor del servicio y lo pusheamos en el observable del usuario. Si vas a implementar un patrón similar a este te recomiendo, eso sí, que al recuperar el token del localstorage, antes de pushearlo al observable lo re-valides contra el servidor para asegurarte que sigue siendo correcto. un saludo y gracias por tu comentario.
