Angular-oauth2-oidc: How to redirect to returnurl after login

[penleychan]

Hi,

I am having trouble understanding how to redirect user back to their requested URL after login.
In my app, users are immediately redirected login page when open, after login they should be redirected to their requested URL.

I have tried using the following callback after login, but no luck.

this.oauthService.tryLogin({
    onTokenReceived: (info) => {
       this.router.navigate([path]);
    }
});

[alexndreazevedo]

It's solved at https://github.com/manfredsteyer/angular-oauth2-oidc/issues/133. Please check the issues before creating a new one.

[penleychan]

Not sure how that issue is related? #133 state that the event is not raised. My issue is router.navigate() does not even fire, (token_recieved event is raised).

[alexndreazevedo]

The callback function you have defined is only being invoked after a few boolean conditions. More specifically, on the last return statement, within a promise chain: oauth-service.ts:1178.

If you carefully check your AuthConfig and go through the method OAuthService.tryLogin(), you may find a return statement that stops the method execution, without invoking the OAuthService.callOnTokenReceivedIfExists().

The best way for to do this redirection would be subscribing the OAuthService.events:

// @TODO: Implement more event handlers
this.oAuthService.events.subscribe(({ type }: OAuthEvent) => {
  switch (type) {
    case 'token_received':
      return this.router.navigate([path]);
  }
});

[penleychan]

I've come to conclusion that router.navigate does not work in the callback or subscribing the events.

For now I've just replaced it with plain old javascript window.location.href

[ryanbuening]

@penleychan I have the same scenario as you, users are immediately redirected login page when open, after login they should be redirected to their requested URL.

What does your logic look like around the window.location.href? Are you doing this in app.component.ts? What is your redirectUri set to in AuthConfig?

Thanks for any tips.

[penleychan]

@ryanbuening I am not using this library anymore, I am just using plain oidc-client.js from here https://github.com/IdentityModel/oidc-client-js

However, you can still get it working with this library, which is similar to any other library.

The way I did it was I had an AuthCallbackComponent and that was my redirectUri.
So basically after login it redirects you to authcallback and that's where you handle all your login stuff (if any) then you redirect user back to where they were before.

[ryanbuening]

@penleychan Thanks. I think I understand the concept, but how were you able to get the requested URL to pass into initImplicitFlow()? I'm using the following in app.component.ts:

this.oauthService.loadDiscoveryDocumentAndTryLogin()
    .then(result => {
        if (!this.oauthService.hasValidIdToken() || !this.oauthService.hasValidAccessToken()) {
            this.oauthService.initImplicitFlow("How do I get the requested URL here?");
        }
    });

but I haven't been able to grab full requested URL in app.component.ts.

[penleychan]

@ryanbuening You would store (w/e storage mechanism you want, that's up to you) the requested URL on your authguard, then when it hit to your authcallback you would redirect the user back.

[ryanbuening]

I think I understand the AuthGuard part, but I'm not sure what you mean by "storing the requested URL on the authguard". Do you store the requested URL in local storage or something? I was under the assumption that I'd be passing the requested URL in the initImplicitFlow(additionalState: string) additionalState parameter.

[penleychan]

@ryanbuening that's not where you pass in requested url, additional state is a param based on oAuth specs for CSRF.

And yes I stored it on local storage.

If you take a look at the source code, you can see what it's doing with that "additionalState" https://github.com/manfredsteyer/angular-oauth2-oidc/blob/master/projects/lib/src/oauth-service.ts#L1109

[ryanbuening]

@penleychan Thanks for your help. I was able to get it working.

[ahmadakra]

Hoping this will save others from going through 15 hours of pain and frustration like I did:

const authConfig: AuthConfig = {

  // ... some config

  // when this is not set to false, the router refuses to 
  // redirect to the requested URL after tryLogin()
  clearHashAfterLogin: false,

 // ... some more config

}

[alxv2016]

Hoping this will save others from going through 15 hours of pain and frustration like I did:

const authConfig: AuthConfig = {

  // ... some config

  // when this is not set to false, the router refuses to 
  // redirect to the requested URL after tryLogin()
  clearHashAfterLogin: false,

 // ... some more config

}

I just wanted to say thanks @ahmadakra, I spend 2 days scratching my head on this issue finally found this thread...This should be set in the documentation honestly. Router will not work on any call back pages if clearHashAfterLogin is not set to false.

[raj-298585]

Hoping this will save others from going through 15 hours of pain and frustration like I did:

const authConfig: AuthConfig = {

  // ... some config

  // when this is not set to false, the router refuses to 
  // redirect to the requested URL after tryLogin()
  clearHashAfterLogin: false,

 // ... some more config

}

Finally found this thread to help me out after scratching my head for 2 days. Just wanted to say thanks to @ahmadakra

[nomuna]

What happens to people who are not using hash in the routes?

I ran into this issue also. I find that the ticket should not be closed. A hard coded redirectUri is not okay in my opinion.

It is reasonable to assume that If I want to access a protected route and I am not logged in that I get redirected to a login page. After that it is also reasonable to expect that I get redirected to the previously requested route (if I have the appropriate authorization of course).

[jeroenheijmans]

I ran into this issue also. I find that the ticket should not be closed.

@nomuna I understand and appreciate that this thread might be a top result when searching, but that's also because it's a bit "all over the place" with various people chiming in with sometimes subtly different scenarios.

The community here is small, but always willing to help. But for contributors it's super hard to keep supporting various people in a thread like this. On top of that, the Original Poster had no initial precise repro for a bug, and closed the thread themselves.

What I recommend then, if you run into a related issue, is to just ask a fresh Stack Overflow question, or open a new GitHub issue if you think you've encountered a bug or missing feature. That gives _you_ the best chance for an answer, and _the community_ a clear thread (assuming you're adding a minimal reproducible scenario, to make helping you as easy as possible).

Sounds reasonable?

---

As a foot note, scanning your remarks: I am _not_ aware of any blockers for using state across redirects with Implicit or Code flow? My sample has a guard that forces you to log in, preserving the _intended_ route, and when you return after logging in interactively it will send you to that intended route.

PS. Note that there's been recent changes, with the latest version (9.2+) of the library I think decodeURIComponent is no longer needed.

Maybe that example helps you out?