Angular-auth-oidc-client: Set dynamic "post_login_route" just before login

[BernhardRode]

He,
i'd like to have my users come back to the page, where they have been, when they started the login.

I could build some workarounds and have the user being redirected using available events, which will lead to many redirects and possible requests. angular-auth-oidc-client already has the post_login_route configuration flag, so i think it would convenient to set the url before login happens like this.oidcSecurityService.setPostLoginRoute(window.location.href); or something. What do you think?

[remkoboschker]

I would be interested in implementing this. I propose the store the post login route in the session store (just like the other data in https://github.com/damienbod/angular-auth-oidc-client/blob/master/projects/angular-auth-oidc-client/src/lib/services/oidc.security.common.ts).

Would it be preferable to automatically redirect to this route if available given trigger_authorization_result_event is set to false or should we store the route en then use it in the authorization_result_event handler.

Also would it be necessary to store the route using the nonce as key to ensure requests do not redirect to the wrong route after previous or failed requests?

Pehaps we could add the route as an extra parameter to the authorize call? It already has the option to specify a custom url handler. So it might be an issue to add it without breaking anything.

[damienbod]

@remkoboschker go for it, thanks!

Greetings Damien

[remkoboschker]

I have implemented a work-around using the session storage to store the postloginroute. But we ran into the issue that when registering a new account with the identity providers there is a email confirmation link that opens a new tab and you have lost the sessionstorage postloginroute. So a solution using sessionstorage for the dynamic post_login_route is a no go. Could use localstorage en clear it after login.

[damienbod]

You would only use localstorage to persist the post login route then?

[remkoboschker]

We have had to switch to using localstorage for tokens as well. But now we have issues where people use one browser to navigate the app and register with our idp, receive a validation email that they open in another browser and then the localstorage options does not work either. So I think I should want to encode a postlogin url in the state parameter. But this can be tampered with and needs validation in the client and even then a nonce value needs to be persisted for validation. So quite a few edge cases here. I think safest would be to encode in state parameter and allow users of the lib to configure storage independently

[damienbod]

added

[hoangngk]

Hi @damienbod and @remkoboschker

Do we have to guide to use this ?

Thanks a lot