3
votes

Problem:

On clicking sign-in angular app correctly sends out request to login.microsoft.com. The request gets a reply with a valid token attached. When executing this on Firefox/Chrome no problem, redirectUri is handled correct and redirects to logged in user page.

On Edge however is seems that some versions of Edge either do not read the reply correct or do not create the login request URL correctly. The resulting redirectUri end at a ./null site (i.e. https://[some URL]/null)

The problem does not exist on debugging where the referrer is localhost, the redirect gets done correctly. It's only when deployed on IIS the redirection leads to incorrect results.

The IIS site has a rewrite rule that redirects http requests to https traffic

20190806 Update:

After looking into it a bit further I found that using localStorage instead of sessionStorage makes the whole thing work well (on Firefox/Chrome/Edge) see also: localStorage not working in Edge? Though that still does not provide the answer as to why sessionStorage didn't work. The version had nothing to do with (though I had two different MS Egde versions on two systems, one worked correct, the other didn't)

Symptoms

It appears to be occurring only on certain Edge version.

Edge version 44.18362.10, EdgeHTML 18.18362 responds as required no problem.

Edge version 44.17763.10, EdgeHTML 18.17763 gives the error

I cannot verify this is the case, upgrading from 17763 => 18392 didn't resolve the problem.

Using

Angular 6.2.9

MsAdalAngular6Service (https://www.npmjs.com/package/microsoft-adal-angular6)

JWT Token bearer.

sessionStorage as token storage => problem is resolved by swapping to localStorage

app.module.ts

MsAdal initiator in imports

MsAdalAngular6Module.forRoot({
      tenant: 'tenantID',
      clientId: 'clientID',
      redirectUri: window.location.origin,
      endpoints: { 
        [SITE ENDPOINTS]
      },
      navigateToLoginRequestUrl: true,
      cacheLocation: 'sessionStorage',
    })

it may be that Edge interprets the window.location.origin incorrectly as it sometimes injects the null in the login request as well.

Tried:

hardcode the redirectUri value

use different redirectUri window constructors ('https://' + windows.location.hostname)

from: https://tosbourn.com/a-fix-for-window-location-origin-in-internet-explorer/

window.location.hostname + (window.location.port ? ':' + window.location.port: '');

a variety of other attempts, all leading to same result.

return redirectUri ends with ./null

Has anyone seen this problem and or know how to resolve the issue?

1

1 Answers

4
votes

This appears to be a documented error. https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/330 https://github.com/AzureAD/azure-activedirectory-library-for-js/wiki/Known-issues-on-Edge#issues

One workaround is to set NavigateToLoginRequestUrl to false in the MSAL config. (I see you have it set to the default setting of true.) If you set it to false then the user won't be redirected to the page where he/she started but in the callback you can reset the browser location to your desired url using window.location.href.