@@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 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, 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 😉
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
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ú
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 😉
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.
7:07 canLoad esta deprecated sugieren canMatch. Gracias por el video :)
Correcto! 👍
A partir de la v.15 canLoad fue marcada como _deprecated_ en favor de canMatch.
@@akotech tendras algùn video actualizado con canMatch?
@@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 😉
Muchas gracias, es difícil encontrar contenido de calidad en Angular en español, he aprendido mucho. De nuevo gracias y quedo pendiente a más videos
Gracias 😊!
que calidad de video y de explicacion estimado me quito el sombrero es usted un crack
Muchas gracias 😊!
un saludo
Genial!
esta brutal el contenido de esta video y del canal
Muchas gracias por tus palabras Andres.
Un saludo
¡Gracias!
Muchas gracias a ti por tu apoyo Andrés! 😊
un saludo
Excelente resumen. Claro y rápido. ¡Muchas gracias!
Increíble, eres el mejor explicando a detalle y de forma sencilla. Muchas gracias!!!
gracias a ti por tus palabras!
un saludo 😉
Muy buen video
Muchas gracias Diego. 😉
un saludo
Soy nuevo en Angular y no entiendo muchas cosas, pero esto si lo entendí. Muy buena explicación. Desde el método básico al avanzado.
Muchas gracias. Un placer haberte podido ayudar. 😉
un saludo
Es increíble lo didáctico del contenido, muy bueno en visualización y lo práctico de sus ejemplos!!
Muchísimas gracias! 😊
Genial!!!!, muy bien explicado. Graciassssss por compartir el conocimiento, son unos capos!!!. Saludos desde Perú
Gracias a ti por tu comentario y un saludo!
Excelente contenido: al grano y muy práctico!
gracias 😊!
Excepcional, felicitaciones hiciste un buen trabajo. Muchas gracias.
Mucha gracias por tus palabras 😊.
un saludo
Excelente tutorial para los roles y permisos. Muchas gracias por el aporte
Gracias a ti por tus palabras!
un saludo
Gran vídeo de gran calidad y que va al punto a tratar, gracias por el aporte.
Gracias por tus palabras Jorge!
un saludo
Muchas gracias, un vídeo muy claro, conciso y útil!!! Felicidades
gracias! 😊
nuevo sub, que manera tan clara de explicar algo que podría considerarse complejo
Gracias y bienvenido Andrés.
un saludo 😉
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.
gracias a ti por tus palabras 😉
Increíblemente claro! Muy buen material. Felicidades
Muchas gracias 😁!
Muy buen video gracias por compartir
Muchas gracias a ti por tu comentario.
un saludo 😉
Excelente explicación !muchas gracias !
Gracias a ti por tus palabras!
un saludo 😉
Gracias, que contenido tan didactico.
Gracias a ti por tus palabras Antony.
un saludo 😉
excelente explicacion, son unos crack. gracias
Muchas gracias Flavio 😊
un saludo
Muchísimas gracias, mi pedido de hace unos meses!!! Muy bien explicado 👍
He tardado un poco más de lo que esperaba en un inicio, pero me alegro que sigas por aquí y que te haya útil.
un saludo 😉
Super ejemplo, muchas gracias!.
gracias a ti por tu comentario 😉!
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 !
Muchísimas gracias por tus palabras Felix!
un saludo
Qué pedazo de contenido! Cada uno de tus videos es oro puro. Muchas gracias por compartir tanto conocimiento y de forma tan clara, crack!
Muchísimas gracias a ti por tus palabras!
un saludo
TODO UN CAPO,. GRACIAS
Que buena explicación.
Muchas gracias. un saludo 😉
Excelente material, gracias !!!
Gracias a ti por tu comentario! 😊
nuevo seguidor!!... un video de calidad gracias!!!....
Muchas gracias y bienvenido! 😊
Excelente explicación
Muchas gracias Nelson!
un saludo
uffff... Gracias! Excelente contenido... Sos un Crack... Saludos y subscrito...
Muchas gracias y bienvenido 😉!
Tome su subscripción caballero!
Buenísimo video! 💪
Gracias y bienvenido! 😊
un saludo
te amo
🤣
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
uy muy buen tutorial me acabo de encontrar tu canal
Gracias 😊!
Que buen video muchas gracias. podrias hacer uno con Interceptores con renovacion del token ? 👏👏👍
Muchas gracias por tu comentario . Me apunto lo del interceptor.
un saludo
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, 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 😉
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
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 tus palabras Arnold 😊.
No lo descarto para un futuro, pero de momento no tengo ningún curso de pago.
un saludo
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 😉
Un crack!!! tienes el video donde creas el LogIn del proyecto?
No lo siento. Pero si te sirve, en la descripción tienes el enlace al repositorio con todo el código.
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']) //
@@akotech perfecto muchas gracias
y si en lugar de canLoad utilizo CanActivate cambia algo?
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.
Muy bueno el contenido, gracias por compartirlo. Tenes algun curso en alguna plataforma?
Entra dentro de mis planes hacer alguno, pero de momento no tengo.
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 😉!
@@akotech Muchas gracias por tu respuesta, me queda claro
Como hacer para que al recargar la pagina nose pierda el inicio de sesion y todo funciuone correctamente
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.
Hola, tienes cursos en línea? SALUDOS
Hola Enrique, tengo planeado hacer un par de ellos a lo largo de este año, pero de momento no tengo ninguno.
un saludo