Microsoft-authentication-library-for-js: Angular 7 loginRedirect example?

[drvan]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Other... Please describe:

Browser:

• [x] Chrome version XX
• [ ] Firefox version XX
• [ ] IE version XX
• [ ] Edge version XX
• [ ] Safari version XX

Library version

Library version: 0.2.4

## Current behavior I tried taking the Angular SPA example and swapping `loginPopup` with `loginRedirect`, but this results in an extra page load for reasons that aren't clear to me. This was mentioned in this issue: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/102 But that issue appears to be abandoned without giving a very descriptive explanation. Previous requests for a loginRedirect example are not Angular specific and aren't particularly helpful for those outside of the Angular world: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/473 The extra page load seems to be removed if you follow the comment here: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/498#issuecomment-449085405 But it's not clear what this actually does, as the documentation for `navigateToLoginRequestUrl` is vague. I also don't know the side effects of changing this parameter and how it might impact my application down the line. In short, I think a lot of dev pain would be reduced if a 'best practices' example existed for using loginRedirect with Angular. ## Expected behavior A sample in the samples directory that would showcase how to properly use loginRedirect, similar to the existing loginPopup sample here: https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-angular/samples ## Minimal reproduction of the problem with instructions

[CraigComeOnThisNameCantBeTaken]

This is exactly the same issue I have been trying to resolve this morning. The flash of the second redirect makes the app look very low quality. Thank you for posting with reference to a fix - now I too am looking at the docs for navigateToLoginRequestUrl..

[zamzowd]

As @Dedme suggests here, I think the redirectUrl should point to an html page not included in the Angular app. This html page should have very little resources - just MSAL.js and a UserAgentApplication constructor with the same config used in the Angular app. The constructor trigger the process to parse the token from the hash and then redirect back to the page that the loginRedirect was initialized from.

I'm trying to check if my company would be ok with uploading my approach somewhere on GitHub.

[alexandria-g]

Something I noticed while working on my own Angular 7 app this week using MSAL - you may have both 'navigateToLoginRequestUri: _true_" AND 'redirectUri: _http://xxxx_' defined.

Expected redirectUri behaviour:

• Upon successful login, redirects the user to the path you specify here.

Expected navigateToLoginRequestUri behaviour:

• Upon successful login, tries to navigate user back to their original location they tried to access before they were directed away to authenticate with Microsoft.

When I had both active in my _app.module.ts_ it would flicker back to the user's original target uri, then redirect them to the path I'd specified in my redirectUri.

To solve this, I removed redirectUri altogether and just left navigateToLoginRequestUri as _true_. Alternatively, you could leave redirectUri intact and change navigateToLoginRequestUri to _false_.

[zamzowd]

@alexandria-g A concern with not specifying a redirectUri:

If unspecified, MSAL.js automatically sets redirectUri to be the URL (minus query parameters and hash) used to first load the page. For a single-page application with routing like Angular, that means that if the page first loads on route http://xxxx/route/to/entity then that's what's used for the redirectUri.

Many OIDC authorities (including Azure AD / Azure AD B2C) require the dev to specify redirect urls for the application registration. Your strategy of not specifying a redirectUri means that the dev would have to list every possible route on the application registration. This might not even be reasonably possible if route parameters are used.

Setting navigateToLoginRequestUri to false just means it stays on the redirect uri after processing the hash. The behavior when it's true is that it saves the url you trigger the login from in storage, and then after processing the hash (normally done on the redirect page), it pulls that login request url back out of storage and redirects the browser to that url.

To reiterate my recommendation: consider having a page on the same domain as the Angular SPA - but outside the SPA - to act as the redirectUri. If you're using Angular CLI, you can include the redirect.html in the assets array of the build options. Setting up the typescript compile and scripts in there is a little tricky, though.

[sameerag]

Tracking this with #786. Same issue as #526.

Also, @negoe to track samples on redirect usage for core and angular.

[leniel]

Guys, can you please shed some light on this specific case? https://stackoverflow.com/q/57085159/114029

[rahulrastogi-git]

@sameerag, can you please provide redirect example, if possible with dummy page which can absorb the reload.

second, i am getting the token from azure ad, which has roles, how can i access those roles in angular.User object is not giving any option to get that information.