0
635
VisualizaçõesTratando de entender las diferencias entre CanActivate y CanActivateChild
Entonces, estoy tratando de proteger el acceso a varias rutas usando guardias. Estoy usando las siguientes rutas para hacerlo:
const adminRoutes : Routes = [ { path: 'admin', component: AdminComponent, canActivate: [ AuthGuardService ], children : [ { path: '', canActivateChild: [ AuthGuardService ], children: [ { path: 'edit', component: DashboardComponent}, { path: '', component: DashboardComponent} ] } ] } ]; He aquí un vistazo a cómo se ve AuthGuardService
import { Injectable } from '@angular/core'; import {CanActivate, Router, ActivatedRouteSnapshot, RouterStateSnapshot} from "@angular/router"; @Injectable() export class AuthGuardService implements CanActivate{ constructor(private router: Router) { } canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot){ console.log("Guarding..."); return this.sessionValid(); } canActivateChild(route: ActivatedRouteSnapshot, state: RouterStateSnapshot){ console.log("Guarding children..."); return this.canActivate(route, state); } sessionValid() : boolean { //tests } } Cuando intento acceder a '/admin' y '/admin/edit' solo con canActivate (se comenta canActivateChild ) la consola muestra
Guarding... Cuando canActivate y canActivateChild , la consola muestra
Guarding children... Cuando me quedo con ambos, vuelve a mostrar Guarding... . Entonces, mi pregunta es ¿cuál es el propósito de tener canActivateChild cuando canActivate protege tanto el elemento raíz como los elementos secundarios?
PD: entiendo que canActivateChild se ejecuta antes de que se active la ruta secundaria. Pero, ¿cuáles son los beneficios de eso? ¿No es suficiente mantener solo uno de ellos?
3 Respostas
Responde à pergunta0
Ambos son importantes porque puede tener diferentes requisitos en los que un usuario puede acceder al componente raíz, pero es posible que no cumpla las condiciones para los componentes secundarios.
Ejemplo: podría tener una situación en la que un usuario debe estar autenticado para navegar al componente raíz, pero debe tener el permiso 'x' para acceder a los componentes secundarios. En casos como este, canActivateChild ahorra mucho tipeo al tener que agregar canActivate guards a cada uno de los elementos secundarios.
EDITAR:
Por ejemplo, puede tener un módulo de administración donde todas las rutas deben protegerse contra la entrada no autorizada:
{ path: 'admin', component: AdminComponent, canActivate: [ AuthGuardService ], children : [ { path: '', component: ..., }, { path: 'manage-users', component: ..., }, { path: 'manage-roles', component: ..., } ] } Esto tendría que ser protegido de arriba hacia abajo. No hay acceso no autorizado a ninguna de las rutas, incluidas la raíz y los niños. En esta situación, canActivate en el nivel raíz funciona muy bien para proteger todo.
Pero también puede haber momentos en los que tenga un módulo de funciones en el que solo ciertos niños deben protegerse:
{ path: 'featureA', component: ..., canActivateChild: [ AuthGuardService ], children : [ { path: 'manage-feature', component: ..., }, { path: 'manage-members', component: ..., } ], {path: 'featureB', component: ...} } En esta situación, tal vez todos los usuarios necesiten llegar a los componentes raíz 'featureA' y 'featureB', pero solo ciertos usuarios deben poder navegar a las rutas secundarias de 'featureA'. En este caso, es más fácil usar un protector en el nivel raíz para proteger a los niños, pero no a la raíz en sí. La alternativa es poner protectores canActivate en cada ruta secundaria, lo que podría volverse tedioso.
Realmente todo depende de sus requisitos, pero puede ser bueno tener ambas opciones de canActivate y canActivateChild .
0
En mi opinión, CanActivate se usa para restringir el acceso desde una determinada ruta y todas las rutas secundarias y CanActivateChild se usa para restringir el acceso a un grupo específico dentro de la ruta CanActivate .
Ejemplo:
{ path: 'admin', component: AdminComponent, canActivate: [AuthGuardService], children : [ { path: 'books', component: ..., }, { path: 'authors', component: ..., }, { path: 'payments', canActivateChild: [AuthGuardService], children: [ { path: 'list', component: ... }, { path: 'list/:id', component: ... } ] } ] } Debido a que necesita dos tipos de validaciones, no puede tener dos métodos canActivate , por lo que necesita canActivateChild para verificar el permiso dentro de la ruta canActivate . Obviamente, puede crear un servicio de guardia diferente ( AuthGuardForChildrenRoutes ) y aún usar el método canActivate , pero ese no es el punto.
0
| No Señor. | PuedeActivar | CanActivateChild |
|---|---|---|
| 1 | Impide el acceso a la ruta principal que también incluye el acceso a todas las rutas secundarias | podemos acceder a la ruta principal, pero si es necesario, podemos elegir bloquear una ruta secundaria en particular mediante canActivateChild |
| 2 | Sí, puede lograr el comportamiento CanActivateChild aplicando CanActivate a todas las rutas secundarias | simplemente agregar CanActivateChild en la ruta principal ahorra mucho tiempo y es más conveniente |
Ahora bien, esta fue la diferencia básica entre canActivate y canActivatedchild
aquí está la situación en la que estos dos podrían usarse
Figura : ruta para ilustrar la diferencia entre CanActivate y CanActivateChild
CanActivate : el estudiante del departamento de informática no puede acceder a otros departamentos
CanActivateChild : el estudiante del departamento de computación tiene acceso al departamento de computación (que es el padre en este caso) pero no puede acceder a un hijo del departamento de computación, es decir, acceso al rol de facultad