Para quienes estaban trabajando con el anterior API, el nuevo es: https://damp-spire-59848.herokuapp.com
Manejo de rutas
Qué aprenderás sobre Angular Router y programación modular
Creando rutas
Creando el Home
Página de categorías
Evitando doble subscribe
RouterLink y RouterActive
Ruta 404
Detalle de cada producto
Parametros URL
Módulos
LazyLoading y CodeSplitting
Programación Modular
Vistas anidadas
Creando el CMS Module
Creando en Website Module
Creando un Shared Module
Precarga de módulos
Precarga de módulos
All Modules y Custom Strategy
QuickLink Strategy
Guardianes
Conoce a los Guardianes
Implementando redirects
Estado de login
Guard para Admin
CanDeactivate
Deployment
Netlify Deployment
Despedida
Despedida
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Es tu turno de continuar explorando los Guards de Angular y sus posibilidades para la segurización de rutas. El reto para ti es crear un Guard que valide el “rol” del usuario logueado y le permita o no entrar a los módulos de administración de tu aplicación.
Recuerda importar los Guards en el routing de tu aplicación, ya sea para bloquear el acceso a los módulos o el acceso a un componente individual.
// app-routing.module.ts
import { AuthGuard } from './modules/shared/guards/auth.guard';
import { AdminGuard } from './modules/shared/guards/admin.guard';
const routes: Routes = [
{
path: 'cms',
loadChildren: () => import('./modules/cms/cms.module').then(m => m.CmsModule),
canActivate: [ AuthGuard, AdminGuard ]
},
];
También puedes segurizar las reglas de tu routing con más de un Guard a la vez, separando así la lógica de autenticación y autorización de los usuarios.
Contribución creada por: Kevin Fiorentino.
Aportes 7
Preguntas 5
Para quienes estaban trabajando con el anterior API, el nuevo es: https://damp-spire-59848.herokuapp.com
Cabe señalar que, es importante asegurarse en el backend que los request a endpoints de administración lo realicen usuarios con dichos roles, no es buena practicar delegar esas verificaciones al front.
Obviamente, aplicar lo que estamos aprendiendo en esta clase mejora mucho la experiencia de usuario y es una primera línea de seguridad para la aplicación.
Ya logré conservar la pagina al recargar, lo que hice fue poner en localstorage un rol en el servicio de auth y le asigno el rol del usuario y si es admin, le doy acceso
canActivate(
route: ActivatedRouteSnapshot,
state: RouterStateSnapshot): Observable<boolean | UrlTree> | Promise<boolean | UrlTree> | boolean | UrlTree {
const token = this.authService.getAdminRole();
if (token!='admin') {
this.router.navigate(['/home']);
return false;
}
return true;
}
en auth service:
getAdminRole(){
const token = localStorage.getItem('role');
return token;
}
Los usuarios del Api/users no llevan el campo rol, por lo que no se puede probar estar parte
{
"id": 1,
"email": "[email protected]",
"password": "changeme",
"name": "Jhon"
},
{
"id": 2,
"email": "[email protected]",
"password": "12345",
"name": "Maria"
},
Esta clase se relaciona en el step19 del repo
https://github.com/platzi/Angular-router/tree/19-step/src/app/guards
Vuelvo a dejar el link con el que he trabajado todos los cursos sin problema.
Si no dejas que cargue la aplicacion y el app component haga la request del get profile no te deja entrar al cms por via url directa, yendo al perfil y despues clickear el boton asegura que la request ya se haya hecho, pero como decia en la clase anterior, es mejor manejar un estado en localstorage que se consulte cuando se cargue la aplicacion sin request, ya sea encriptando el usuario en el token o algo parecido. A LOS QUE LES NIEGA EL ACCESO TIENEN QUE ESPERAR A QUE LA APP CONSULTE EL GET PROFILE, no es que la aplicación este mala.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?