web-dev-qa-db-fra.com

CanActivate contre CanActivateChild avec des itinéraires sans composant

La documentation angular2 sur Route Guards ne m'a pas permis de savoir quand il convenait d'utiliser un CanActivate gardes par rapport à un CanActivateChild gardien associé à des itinéraires sans composant.

TL; DR: à quoi sert-il d'avoir canActivateChild quand je peux utiliser des routes sans composant avec canActivate pour atteindre le même effet?

Version longue:

Nous pouvons avoir plusieurs gardes à tous les niveaux d'une hiérarchie de routage. Le routeur vérifie d'abord les gardes CanDeactivate et CanActivateChild, de la route enfant la plus profonde au sommet. Ensuite, il vérifie les gardes CanActivate du haut vers le plus petit des parcours enfants.

Je comprends que CanActivateChild est coché de bas en haut et que CanActivate est coché de haut en bas. Ce qui n'a pas de sens pour moi, c'est l'exemple suivant donné dans la documentation:

@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 {}

Donc, le chemin admin a un itinéraire sans composant:

En examinant notre route enfant sous AdminComponent, nous avons une route avec un chemin et une propriété children, mais elle n’utilise pas de composant. Nous n'avons pas commis d'erreur dans notre configuration, car nous pouvons utiliser un itinéraire sans composant.

Pourquoi le code dans ce cas insère-t-il AuthGuard dans le composant enfant et dans le composant racine (chemin admin)? Ne serait-il pas suffisant de garder à la racine?

J'ai créé un plunkr basé sur l'exemple qui supprime le canActivateChild: [AuthGuard] et ajoute un bouton de déconnexion sur le AdminDashboard. Effectivement, le canActivate de la route parente est toujours protégé, alors quel est l’intérêt d’avoir canActivateChild lorsque je peux utiliser des routes sans composant avec canActivate?

angularangular2-routing
48
Johannes Rudolph

à partir de la documentation:

Lorsque nous avons appris la protection des itinéraires avec CanActivate, nous pouvons également protéger les itinéraires enfants avec CanActivateChild Guard. La garde CanActivateChild fonctionne de la même manière que la garde CanActivate, mais la différence est son exécution avant que chaque route enfant ne soit activée . Nous avons protégé notre module de fonctionnalités admin contre tout accès non autorisé, mais nous pourrions également protéger les itinéraires enfants au sein de notre module de fonctionnalités .

Voici un exemple pratique:

  1. navigation vers /admin
  2. canActivate est coché
  3. Vous naviguez entre les enfants de /admin route, mais canActivate n'est pas appelé car il protège /admin
  4. canActivateChild est appelé à chaque changement de fils de la route sur lequel il est défini.

J'espère que cela vous aidera. Si cela n'est pas encore clair, vous pouvez vérifier certaines fonctionnalités en ajoutant des gardes qui les déboguent.

43
code ninja

Dans le monde réel, j'estime qu'il est redondant d'utiliser la même protection pour le parent et tous ses enfants.

Pour un meilleur exemple, supposons que vous ayez des rôles pour les utilisateurs administrateurs (Édition/Affichage), vous pouvez ajouter une protection pour les onglets "Éditer" uniquement.

    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 }
            ]
          }
        ]
      }
    ])
7
Peter Li

J'ai également confondu la documentation d'angular2 sur routeGuard. Quelle est la différence entre le CanActivate guard et le CanActivateChild guard.

J'ai quelques résultats, j'espère que cela vous aidera.

dans le auth-guard.service.ts fichier

  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);
}

parce que la méthode canActivate est appelée dans la fonction canActivateChild. vous pouvez écrire un extrait de code qui n'appelle pas la méthode canActivate dans la fonction canActivateChild.

3
crystalw

Une des raisons pour laquelle je peux penser est timeouts.

Je commence à travailler avec Angular 2, à l'aide d'un fournisseur d'authentification. Ce fournisseur expire une session inactive depuis plus d'un certain temps.

Dans une situation courante où vous laissez votre ordinateur connecté et la session expirée, la navigation suivante que vous essayez DOIT valider votre situation actuelle. Si vous naviguez entre des itinéraires enfants, je pense que CanActivateChild est la protection qui détectera la session expirée et déclenchera une redirection vers la connexion, tandis que CanActivate ne se déclenchera pas du tout.

Disclaimer: Cela vient de mon esprit, je ne l'ai pas encore implémenté.

2
Alejandro Gianetti

TL; DR:CanActivate et CanActivateChild ne sont pas destinés à une route sans composant.

Je pense que les docs ont simplement négligé l'inutile des deux gardes dans un itinéraire sans composant, car l'intention était simplement de démontrer le parcours sans composant dans un point particulier des docs et l'utilisation des deux gardes dans un autre.

L'utilisation des deux gardes peut être très utile dans des scénarios spécifiques, par exemple: Un tableau de bord d'administration permettant à l'utilisateur de se connecter pour voir plusieurs composants, tels que le mailing, les statistiques de journalisation, l'utilisation des ressources, etc. - à ce niveau, l'accès est limité par le CanActivate guard - en essayant de naviguer dans chaque composant, les rôles de chaque utilisateur admin sont vérifiés par le CanActivateChild guard.

1
Ravid Goldenberg

Et si vous avez 10 enfants définis.

Ensuite, canActivateChild n'a besoin d'aller au même endroit que s'ils ont tous une exigence commune, par opposition à 10 canActivate sur chaque enfant.

0
Simon_Weaver