angular: CanActivate not called on redirectTo router rule; but no error either
I’m submitting a…
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
Current behavior
When defining a route with redirectTo
and canActivate
properties, there is no error (as there would be if there were, say, redirectTo
and children
properties on the same route).
But, while it is apparently allowed, it is not honored. The canActivate
is never called, and the redirectTo
is simply processed.
E.G.
{ path:"**",
//component: MyComponent,
redirectTo: "foo",
canActivate: [ MyGuard ]
}
If redirectTo
is commented out and component
uncommented, MyGuard
runs just fine.
Expected behavior
There should either be an error thrown if canActivate
is not allowed for redirectTo
routes,
or, canActivate
should be processed the same way it is for Components.
What is the motivation / use case for changing the behavior?
Since there is no resolveRedirectTo
as there was in AngularJS,
and there is no ability to define or invoke a function/service on the redirectTo
property (to calculate the path to redirect to),
there is a need to invoke that service and redirect programmatically via canActivate (for lack of a better place to put it).
Plus, I would rather see a (bogus) redirectTo
property rather than a bogus Component
property (since canActivate is always going to redirect because we are trying to recreate the missing resolveRedirectTo
facility).
Environment
Angular version: 4.3.1
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 86
- Comments: 19 (1 by maintainers)
Commits related to this issue
- refactor(router): Produce error message when canActivate is used with redirectTo Redirects in the router are processed before activations. This means that a canActivate will never execute if a route ... — committed to atscott/angular by atscott 4 years ago
- refactor(router): Produce error message when canActivate is used with redirectTo Redirects in the router are processed before activations. This means that a canActivate will never execute if a route ... — committed to atscott/angular by atscott 4 years ago
The current workaround is to create a dummy component and call the redirect logic inside a guard. Not pretty but it does the job.
need updates on it. I am also facing same problem
Is there any update regarding this issue?
Do we have update on this?
i’ve the same problem, any news?
For me this issue was occurred due to incorrect position of ** route path. Whenever you are importing “**” route path make sure that you add this in the end of your import list. For example:
Hi all, I’m updating this to be a feature request / use-case that doesn’t have a clear recommendation (docs needed, error message needed). In the meantime, maybe a cleaner solution than a dummy component would be to have a route with an empty children array. This route could still be “activated” and would run the guards, allowing you to redirect properly.
https://stackblitz.com/edit/angular-ivy-router-base-nka13t?file=src%2Fapp%2Fapp.module.ts
Oh, I agree…there should be bug fixes to make existing features work. I groan at the religious adherence to so-called “agile” thinking and doing multiple full version number releases a year…If were king the practice would be to make APIs stable, and functioning correctly before letting some newbie create new features and break old ones. (Of course, that should go also for all software from Apple, Google, Facebook, Microsoft, etc, etc, etc).
this is working solution for me in Angular 11
in the route guard you have the logic to redirect router however you like.
OMFG…until a fix…I am the one who wrote this original bug report and that was 3 and a half YEARS ago! I’ve actually retired since, and a good thing I didn’t hold my breath for this and many other bugs to be fixed over the years. I don’t know what IS being worked on but like most programmers, they want to work on new stuff rather than make the existing stuff work correctly.
Although this is technically working (and probably the workaround most people are using right now) it is not a solution because you are not using the redirectTo parameter, which handles the redirection logic. So it can be a temporary workaround until an actual fix for this bug comes around.