canActivate=>false can result in blank screen/dead link

I’m submitting a … (check one with “x”)

[ X ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

canActivate, canActivateChild will result in NavigationCancel event if ‘false’/reject() happens in the Guard. Additionally the URL is reset to the base path before the navigation attempt (as though to leave the user on the page they navigated from).

This current behavior means that if you just go directly to a location in your browser (e.g. localhost:4200/some-guarded-route) and it returns false the URL will read “localhost:4200/” with a blank page as navigation is canceled.

Expected behavior

The right behavior to me seems that the router should try to see if there are further matches in the routing table (i.e. the guard ‘false’ case would cover the use case scenario of #14515). By continuing down the route table the behavior would be to land on ‘**’ route in the worst case while also enabling conditional routing.

Minimally NavigationCancel event should determine if the resetUrlToCurrentUrlTree is an already displayed route (either rendering it if necessary or doing nothing if it’s already rendered).

I will see if I can issue a PR to fix this for review. Will need to determine what the side effects would be for cases where people would expect just to stay on the currently rendered page (considering it was already rendered). However, to me I think the correct behavior for a dead link should be to go down the route table and hit ‘**’ for a 404 or something vs doing nothing when the user clicks on it and rendering nothing if the user hits the route directly before any route has been rendered.

Minimal reproduction of the problem with instructions

Plunker won’t work for this because you would need to be able to hit the route as though it was bookmarked to reproduce.

Effectively just create project using CLI, create a route guard, return false in the methods. Then attempt to hit the route directly without loading a root non-guarded route first.

What is the motivation / use case for changing the behavior?

Motivation is that you won’t have the user on a blank screen if they happen to hit a guarded route without meeting the conditions.

Second part is that by resolving these scenarios by continuing down the route table you would enable conditional routing for scenarios such as:

Creating routes like: localhost:4200/:organization localhost:4200/:user

If the route guard found a valid organization it could allow the request to move forward vs user. This is all gravy. A start is to not give the user a blank page when resetting the route via resetUrlToCurrentUrlTree when the current Url wasn’t rendered in the first place.

Please tell us about your environment:

Mac OS Sierra (10.12.4), WebStorm, NPM, ng serve

• Angular version: Angular 4.0.2

• Browser: Chrome 57

• Language: TypeScript 2.2.2

• Node (for AoT issues): node --version =
  Node 7.9

[mseltene]

Hi all, try below code… setTimeout

import { Injectable } from '@angular/core';
import { CanActivate, ActivatedRouteSnapshot, RouterStateSnapshot, Router } from '@angular/router';
import { Observable } from 'rxjs/Observable';
import { AuthService } from './auth.service';

@Injectable()
export class AuthGuard implements CanActivate {
   constructor( private authService : AuthService, private router: Router) {}

  canActivate(
    next: ActivatedRouteSnapshot,
    state: RouterStateSnapshot): Observable<boolean> | Promise<boolean> | boolean {

    setTimeout(()=>{ //timer trick
      if(this.authService.isUserEmailLoggedIn==false){ 
        this.router.navigate(['']); //home page, usually logged out state
      }else{
       this.router.navigate(['dashboard']); //redirect to your after loggedin page
      } 
    },500) //default 500 works fine, but experiment with 600, 700, 800. lower than 500 was not stable, sometimes kicks you to home page.
  return this.authService.isUserEmailLoggedIn;
  }
}

[chulian1819]

seriously, for simple things like this, angular is not production ready, will have to drop angular and use something more mature, or at least one that doesn’t fail at the most basic things like this one. Having too many issues with simple things, trying to build a prototype to show to the company why we should move to angular, bur right now I have more reasons why not to move to angular and just run away from it after so much frustration.

Ps: it’s already been a year since this bug was reported, I know I’m not helping solving the bugs, I know that ang team might be solving other critical bugs, but this gives you an idea of the current precarious state of this library.