angular: router CanLoad Route guard broken for common use case

My Current workaround (ng 6 with rxjs 6)

export class AuthGuard implements CanLoad{
  constructor( private router: Router ) {}
  public canLoad(route: Route): boolean {
    if(this.isAuthenticated){
      return true;
    }
    this.router.events.pipe(first(_ => _ instanceof NavigationCancel)).subscribe((event: NavigationCancel) => {
      // event.url is the target route the user was attempting to reach
      this.redirectToLogin(event.url);
    });
   // returning false cancels the navigation triggering the code above
    return false;
  }

  private isAuthenticated(): boolean {
   ...
  }
  private redirectToLogin(redirect:string):void {
     this.router.navigate(['/login'], {
      queryParams: {
        redirect: redirect
      }
    })
  }
}

@figuerres This bug negates the usefulness of canLoad guard in many cases.

Common case:

1. The user bookmarks a URL into a lazy-loaded module that requires auth. (let’s call it 1.chunk)
2. The user sends the url to a friend
3. Sometimes later, the friend clicks on the link in step 1
4. canLoad() kicks-in & wants to possibly prevent an unnecessary fetch of 1.chunk
5. The friend is redirected to the login page to authenticated first
6. The friend is authenticated, but the system has no recollection of where to redirect the friend to.
7. Very unhappy friend.

The question is, how can we send a link to a lazy-loaded canLoad-guarded module and expect the recipient of the link to make it to the destination, post authentication, in this example?

Workaround: disable canLoad guards and let canActivate do the guarding. Yes, your friend just paid the price of loading a chuck, and probably decided not to even follow up with auth.

@Toxicable This is not a special case. Bookmarking in this example is a normal and a common use-case.

there’s an even more angular compliant solution without using window.location:

export class AuthnGuard implements CanLoad {
  constructor(private authnService: AuthnService, private router: Router) { }

  canLoad( ): Observable<boolean> | Promise<boolean> | boolean {
    const navigation = this.router.getCurrentNavigation();
    let url = '/';

    if (navigation) {
      url = navigation.extractedUrl.toString();
    }
    this.authnService.storeRedirectUrl(url);

…

Here is a more general statement of the problem:

canLoad cannot decide to load a module if the logic needs the route. for example if the module is Admin and the admin module has a view that it can route to called roles and the navigate route is called /admin/manage/roles can load does not know that the target is manage/roles it only sees that the admin module is the target.

also if a user enters a full url like https://myapp.com/myaccount/orders/list can load can use the location url to see what the target path is. but if you call navigate( ‘/myaccount/orders/list’) the can load function can not see that path / route

so in any case where the user enters the url can load can see the route but a call from navigate blinds can load to the the same information.

that cripples the utility of can load when the application does navigation. but can activate does not suffer this route blandness problem.

this difference means that the application has to be designed to not navigate into any feature that needs a can load guard if it needs the route.

After hours of frustration, I came up with a solution that in my case works perfectly.

canLoad(route: Route) {
        if (this.auth.authenticated) {
            return true;
        }

        this.auth.redirectUrl = window.location.pathname;
        this.router.navigate(['/login']);
        return new Promise((resolve) => {
            resolve();
        })
    }

auth is my Authentication Service auth.redirectUrl is where my Authentication Service navigates the user once authentication succeeds

Basically the Router only knows how to handle true or a Promise. If you return false it throws one or more errors.

@ivanpadavan that only works if the user has entered a url to load the application.

if the app is running and the code issues a navigate request that hit’s a can load the path has not been loaded yet, the navigation has not been sent to the browser. so that does not fix a very common problem.

the problem has to do with loading a module and that if the guard needs to call an auth that we do not have the full url for the child to use in the post login stage. this is not an issue if your login process does not need to do navigation. the other part is that the can load is only able to know the module to be loaded and not which view is the target so it can’t do permission filtering past module level. each item can be worked past

by contrast can activate has the full path .

i think they were adding the full path to can load to solve this.

Can load does not give the target route, it only gives the target module name. Can activate gives the target route. That is the problem, that is all that is needed to fix the can load interface