link - router.navigate angular 5
CanActivate vs. CanActivateChild con rutas sin componentes (4)
En el mundo real, siento que es redundante usar el mismo guardia para el padre y todos sus hijos.
Para un mejor ejemplo, supongamos que tiene funciones para usuarios administrativos (Editar / Ver), puede agregar un protector para las pestañas solo "Editar".
RouterModule.forChild([
{
path: ''admin'',
component: AdminComponent,
canActivate: [AuthGuard], //1 - redirect to login page if not logged in
children: [
//View Access
{
......
},
//Edit Access
{
path: '''',
canActivateChild: [EditGuard], //2 - display "you don''t have Edit permission to access this page"
children: [
{ path: ''crises'', component: ManageCrisesComponent },
{ path: ''heroes'', component: ManageHeroesComponent },
{ path: '''', component: AdminDashboardComponent }
]
}
]
}
])
La documentación de angular2 sobre Route Guards no me dejó claro cuándo es apropiado usar un CanActivate
contra un CanActivateChild
en combinación con rutas sin componente.
TL; DR: ¿De qué canActivateChild
cuando puedo usar rutas sin canActivate
con canActivate
para lograr el mismo efecto?
Versión larga:
Podemos tener múltiples guardias en cada nivel de una jerarquía de enrutamiento. El enrutador comprueba primero las protecciones CanDeactivate y CanActivateChild, desde la ruta secundaria más profunda hasta la superior. Luego verifica las protecciones CanActivate de arriba hacia abajo a la ruta secundaria más profunda.
Veo que CanActivateChild
está marcado de abajo hacia arriba y CanActivate
está marcado de arriba hacia abajo. Lo que no tiene sentido para mí es el siguiente ejemplo dado en los documentos:
@NgModule({
imports: [
RouterModule.forChild([
{
path: ''admin'',
component: AdminComponent,
canActivate: [AuthGuard],
children: [
{
path: '''',
canActivateChild: [AuthGuard],
children: [
{ path: ''crises'', component: ManageCrisesComponent },
{ path: ''heroes'', component: ManageHeroesComponent },
{ path: '''', component: AdminDashboardComponent }
]
}
]
}
])
],
exports: [
RouterModule
]
})
export class AdminRoutingModule {}
Entonces la ruta de admin
tiene una ruta sin componentes:
En cuanto a nuestra ruta secundaria en AdminComponent, tenemos una ruta con una ruta de acceso y una propiedad secundaria pero no está utilizando un componente. No hemos cometido un error en nuestra configuración, porque podemos usar una ruta sin componentes.
¿Por qué el código en este caso está insertando AuthGuard
en el elemento secundario y en el componente raíz ( admin
ruta)? No sería suficiente para proteger a la raíz?
plunkr un plunkr basado en la muestra que elimina canActivateChild: [AuthGuard]
y agrega un botón de cierre de sesión en AdminDashboard
. Efectivamente, el canActivate
de la ruta padre todavía guarda, entonces ¿de qué canActivateChild
tener canActivateChild
cuando puedo usar rutas sin canActivate
con canActivate
?
También confundí la documentación de angular2 sobre routeGuard. ¿ CanActivate
es la diferencia entre CanActivate
y CanActivateChild
?
Tengo algunos hallazgos, espero que esto te ayude.
en el archivo auth-guard.service.ts
canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean {
let url: string = state.url;
return this.checkLogin(url);
}
canActivateChild(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): boolean {
return this.canActivate(route, state);
}
porque se canActivate
método canActivate
en la función canActivateChild
. puede escribir un fragmento de código que no llame al método canActivate
en la función canActivateChild
.
Una razón por la que puedo pensar es en los tiempos de espera .
Estoy empezando a trabajar con Angular 2, usando un proveedor de autenticación. Este proveedor caduca una sesión que ha estado inactiva durante más de una cierta cantidad de tiempo.
En una situación común en la que deja su computadora conectada y su sesión expira, la próxima navegación que intente DEBE validar su situación actual. Si está navegando entre rutas secundarias, creo que CanActivateChild
es el guardián que detectará la sesión caducada y activará una redirección para iniciar sesión, mientras que CanActivate
no se activará en absoluto.
Descargo de responsabilidad: Esto vino desde lo más alto de mi cabeza, aún no lo he implementado.
Como aprendimos sobre cómo proteger las rutas con CanActivate, también podemos proteger las rutas secundarias con CanActivateChild Guard. El protector CanActivateChild funciona de manera similar al protector CanActivate, pero la diferencia es su ejecución antes de que se active cada ruta hija . Protegimos nuestro módulo de características de administración del acceso no autorizado, pero también pudimos proteger las rutas secundarias dentro de nuestro módulo de características .
Aquí hay un ejemplo práctico:
- navegando a
/admin
-
canActivate
está marcado - Navega entre los hijos de
/admin
route, perocanActivate
no se llama porque protege/admin
-
canActivateChild
secanActivateChild
siempre que se cambia entre hijos de la ruta definida.
Espero que esto lo ayude, si aún no está claro, puede verificar la funcionalidad específica agregando guardias que los depuren.