Differenza tra canLoad e canActivate di Angular?

100

Qual'è la differenza tra canLoade canActivate?

export interface Route {
  path?: string;
  pathMatch?: string;
  matcher?: UrlMatcher;
  component?: Type<any>;
  redirectTo?: string;
  outlet?: string;
  canActivate?: any[];
  canActivateChild?: any[];
  canDeactivate?: any[];
  canLoad?: any[];
  data?: Data;
  resolve?: ResolveData;
  children?: Routes;
  loadChildren?: LoadChildren;
}

Quando dovrei quale di loro?

angular 
— Yoav Schniederman
fonte

Risposte:

99

canActivate viene utilizzato per impedire a utenti non autorizzati di accedere a determinate rotte. Consulta la documentazione per maggiori informazioni.

canLoad viene utilizzato per impedire all'applicazione di caricare pigramente interi moduli se l'utente non è autorizzato a farlo.

Vedere la documentazione e l'esempio di seguito per ulteriori informazioni.

{
    path: 'admin',
    loadChildren: 'app/admin/admin.module#AdminModule',
    canLoad: [AuthGuard]
},

Con questo codice, il codice per AdminModule verrà caricato nell'applicazione solo se AuthGuard ritorna true.

Se l'utente non è autorizzato ad accedere a questa rotta, e avessimo usato solo una canActivateguardia, AdminModuleverrebbe caricata, anche se l'utente non sarebbe in grado di accedere a quella rotta.

— Fredrik Lundin
fonte
6
Se utilizzo canActivatenello scenario precedente, quale sarà la differenza?
— k11k2
3
@ k11k2 con il canActivemodulo verrà caricato (F12> Sources - in chrome). Puoi vedere i file .js lì. Con canLoadquesti moduli (file .js) non verranno caricati :) Controlla la mia risposta sopra dove l'ho spiegata meglio
— DiPix
23
Che dire dello scenario in cui l'amministratore ha effettuato l'accesso, quindi il modulo di amministrazione è stato caricato tramite canLoadrestituisce true e quindi si disconnette dall'applicazione. Ora, un utente non amministratore accede allo stesso browser, come funziona? Il modulo caricato è stato sfrattato o rimosso dalla cache?
— Keerthivasan
2
@Keerthivasan nulla obbliga a rimuovere il blocco precedentemente caricato del pigro AdminModule quando un utente si disconnette e accede di nuovo con un account diverso che non dispone di autorizzazioni sufficienti per caricare AdminModule. Tuttavia, non si otterrà comunque l'accesso ... a meno che non si abbia un modulo memorizzato nella cache caricato. Non penso che sia un vero problema di sicurezza poiché di solito un dispositivo è un vero utente
— hastrb
1
@ sgClaudia98 puoi usare entrambi, ma c'è un rigido ordine di esecuzione delle guardie. per questo non fa differenza nel tuo caso quanto ho affermato poco prima. Penso di aver messo una spiegazione molto dettagliata nel mio primo commento. Sarebbe un caso piuttosto strano se al giorno d'oggi ci fosse un dispositivo e l'accesso amministratore / non amministratore uno per uno.
— hastrb
36
  • CanActivate - Decide se un percorso può essere attivato, questa guardia potrebbe non essere il modo migliore per i moduli di funzionalità che sono caricati in modo pigro, poiché questa guardia caricherà sempre il modulo in memoria, anche se la guardia ha restituito false, il che significa che l'utente non è autorizzato ad accedere la strada.
  • CanLoad : decide se un modulo può essere caricato pigramente, controlla se un percorso può anche essere caricato. Ciò diventa utile per i moduli di funzionalità caricati in modo lento. Non si caricheranno nemmeno se la guardia restituisce false.

Questo è un test che ho fatto su entrambe le guardie con un modulo di funzionalità che è caricato in modo pigro:

1. CanActivate Guard Test

noterai nella parte inferiore della pagina Rete che ha effettuato 24 richieste con dimensioni di 9,5 MB trasferite terminando in 3,34 secondi e caricate completamente in 3,47 secondi.

CanActivate Guard Test su Lazy Loaded Feature Module

1. CanLoad Guard Test

qui vedrai la grande differenza quando abbiamo utilizzato CanLoad Guard poiché il browser ha effettuato solo 18 richieste con dimensioni di 9,2 MB trasferite che terminano in 2,64 secondi e completamente caricato 2,59 secondi.

Test di CanLoad Guard sul modulo Feature Loaded Lazy

CanLoad Guard non carica mai i dati del modulo se l'utente non è autorizzato e questo ti dà maggiori prestazioni poiché il tempo di caricamento è diminuito di quasi 1 secondo e questo è un tempo enorme nel caricamento delle pagine web, senza dubbio dipende dalle dimensioni del modulo.

Suggerimento: se vuoi fare il test sul tuo progetto assicurati che la Disable Cachecasella di controllo nella scheda di rete sia selezionata, è contrassegnata nella prima immagine

— Mahmoud Fawzy
fonte
3
Solo per non confondere qualcuno .. 403 è Forbbiden, non Unauthorized che è 401.
— hastrb
20

Per quanto riguarda la domanda dai commenti in altri post "Se uso canActivate nello scenario sopra, quale sarà la differenza?"

In realtà per l'utente non ci sarà alcuna differenza, non avrà alcun accesso alla pagina in entrambi i casi. Sebbene ci sia una differenza nascosta . Se premi F12 e ti sposti su Sorgenti (in Chrome) dove sono i file di download. Quindi puoi vedere che nel caso in cui con canActive sia stato scaricato il file con il codice ( chunk.js ). Anche se non hai accesso alla pagina. inserisci qui la descrizione dell'immagine

Ma nel caso con canLoad non ci sarà alcun file chunk.js con il codice sorgente.

inserisci qui la descrizione dell'immagine

Quindi, come puoi vedere, questo ha davvero un grande impatto per la sicurezza.

E ovviamente non dimenticare che canLoad può essere utilizzato solo per i moduli LazyLoaded .

— DiPix
fonte
3
non riesco a vedere alcun blocco per il modulo di caricamento lento nella mia scheda di rete ma le rotte funzionano come previsto come posso confermare il caricamento dei miei moduli su richiesta o no?
— k11k2
@ k11k2 se vuoi vedere di quale file fa parte un modulo, aggiungi semplicemente debugger;un'istruzione nel costruttore per uno dei componenti in quel modulo. È quindi possibile vedere se è stato caricato come un blocco separato o incluso in un modulo come main. Se hai riferimenti a componenti in un modulo pigro che non sono isolati da quel modulo, potrebbe essere caricato comunque. Se vedi questo, significa che stai filtrando in base a qualcosa di diverso dai file JS, o hai bisogno di suddividere il tuo modulo pigro in parti comuni e "veramente pigre".
— Simon_Weaver
@ k11k2 Penso che il tuo "modulo di caricamento lento" non venga caricato pigramente. Assicurati di aver usato la loadChildrenproprietà come parte del percorso del tuo modulo pigro.
— hastrb
16

canActivate viene utilizzato per prevenire un utente non autorizzato

canLoad viene utilizzato per impedire l'intero modulo dell'app

Esempio di canActivate :

{ path: 'product',canActivate:[RouteGaurd], component : ProductComponent }

Esempio di canLoad :

{ path: 'user' , canLoad: [AuthenticGuard], loadChildren : './user/user.module#UserModule' }
— Sagar Jadhav
fonte
Per i futuri lettori, l'esempio di canActive non è pigro, ma canLoad è .. dovuto ad avere loadChildren. Inoltre, una versione recente di loadChildren: () => import('./user/user.module').then(m => m.UserModule)
— angular
Spiegazione molto semplice, mi è piaciuto :)
— KTM
16

Il CanLoad Guard impedisce il caricamento del modulo Lazy Loaded. Generalmente usiamo questa guardia quando non vogliamo che un utente non autorizzato navighi verso uno qualsiasi dei percorsi del modulo e fermi anche quindi vedere il codice sorgente del modulo.

Angular fornisce canActivate Guard, che impedisce a utenti non autorizzati di accedere al percorso. Ma non impedisce il download del modulo. L'utente può utilizzare la console per sviluppatori Chrome per vedere il codice sorgente. CanLoad Guard impedisce il download del modulo.

In realtà, CanLoad protegge un modulo da caricare, ma una volta caricato il modulo, CanLoad guard non farà nulla. Supponiamo di aver protetto il caricamento di un modulo utilizzando CanLoad guard per utenti non autenticati. Quando l'utente ha effettuato l'accesso, quel modulo sarà applicabile per essere caricato e saremo in grado di navigare nei percorsi figli configurati da quel modulo. Ma quando l'utente è disconnesso, sarà comunque in grado di navigare in quei percorsi figli perché il modulo è già caricato. In questo caso, se vogliamo proteggere i percorsi dei bambini da utenti non autorizzati, dobbiamo anche utilizzare CanActivate guard.

Usa CanLoad prima di caricare AdminModule:

  {
        path: 'admin',
        loadChildren: 'app/admin/admin.module#AdminModule',
        canLoad: [ AuthGuardService ]
      },

Dopo aver caricato AdminModule, nel modulo AdminRouting possiamo usare CanActive per proteggere i bambini da utenti non autorizzati come di seguito:

{ 
      path: '',
      component: AdminComponent,
      children: [ 
        {
          path: 'person-list',
          component: PersonListComponent,
          canActivate: [ AuthGuardService ]
        }
      ]
    }
— Mohammad niazmand
fonte
Quindi si dovrebbe usare sia canLoad che canActivate?
— Tarida George,
0

canActivate se l'utente non autorizzato entra ancora carica quel modulo. è necessario canLoad per valutare se è necessario caricarlo.

— LiHao
fonte
0

È importante notare che canLoad non impedirà a qualcuno di ottenere il tuo codice sorgente. Il .js non verrà scaricato dal browser a meno che l'utente non sia autorizzato, ma puoi forzare un download manuale emettendo un'importazione ('./ xxxxx.js') sulla console del browser.

Il nome del modulo può essere facilmente trovato su main.js nella definizione dei percorsi.

— Ivan Muricy
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.