microsoft-authentication-library-for-js: First login fails, second login redirects to ".com/null"

I’m submitting a…


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

Browser:

Edge version: 44.18362.387
Chrome version XX
Firefox version XX
IE version XX
Safari version XX

Library version


Library version: 1.1.3

Current behavior

Over the last month, users on Edge have been reporting that they get a sort of “double login issue”. When presented with the login screen, they choose the account to authenticate with and are redirected back to the app. At this point, they’re redirected back to the login page a second time, they choose their account, and are returned to the site correctly on return. However, getting a consistent repro has been problematic.

Today we finally have a user on Edge (one of our offsite vendors) who can consistently repro the issue. Unfortunately, no errors show in the console, and the user was unable to export the network trace HAR as the option was greyed out in Edge browser. They did however take screenshots: https://i.imgur.com/TjIShD5.png

On the second redirect back to the site, it seems the user is being sent to techskillsforbusiness.com/null rather than the correct redirectUri

The application uses the following configuration for MSAL:

const isIE = () => {
  const ua = window.navigator.userAgent;
  const msie = ua.indexOf('MSIE ') > -1;
  const msie11 = ua.indexOf('Trident/') > -1;

  return msie || msie11;
};

const configuration = {
      auth: {
        authority: 'https://login.microsoftonline.com/common/',
        clientId: process.env.REACT_AUTHENTICATION_CLIENT_ID,
        navigateToLoginRequestUrl: true,
        redirectUri: window.location.origin,
        postLogoutRedirectUri: window.location.origin,
        validateAuthority: true
      },
      cache: {
        cacheLocation: 'sessionStorage',
        storeAuthStateInCookie: isIE()
      }
    },
    parameters: {
      scopes: ['user.read', 'openid', 'profile'],
      prompt: 'select_account'
    },
    type: LoginType.Redirect
}

The redirect to /null is a high priority breaking issue for us which is blocking the launch. As an initial step, I’ve enabled a logger to get a verbose trace of everything that occurs and will update the bug when the user is able to test again.

With the limited information here, any idea if this is a known issue? Any troubleshooting advice would also be greatly appreciated.

Seems like this could be related to the following issues: https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/347 (redirect to /null) https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/981 (double login) https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/1035 (double login)

Expected behavior

User should be successfully logged in on the first attempt and redirected to the correct redirectUri.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (17 by maintainers)

Most upvoted comments

@AndrewCraswell do you know, whether users that are facing the issue with double navigation + /null navigation are using Edge’s InPrivate mode? Because I see the exact same behavior in this mode in Edge. I’ve debugged the issue a bit and it looks to me that Edge in InPrivate mode clears up the localStorage/sessionStorage when it leaves the domain, so in our case each time a redirect to login page appears the application’s cache is dropped.

As result when you are navigated back to the application the msal.login.request record is removed from the storage, and MSAL have no idea how to navigate you back.

For me changing the storage type to localStorage (fixed double login in my case) and enabling storing in cookies (fixes /null navigation) fixed the situation:

cache: {
	cacheLocation: 'localStorage',
	storeAuthStateInCookie: true
},

anton-gorbikov on Oct 21, 2019

For those with this issue, please try msal@1.2.0-beta.1, which contains a fix (if msal is unable to load the correct redirect uri, it will redirect your app to your home page, instead of /null). As noted above, if this is not acceptable for your use case, I recommend setting navigateToLoginRequestUrl to false. We’ll continue to investigate the root cause, but this should be acceptable in the interest of not completely break your app. Any feedback is appreciated.

@AndrewCraswell We’re working now to better understand the root cause of the timeouts (there’s another MSFT team that is also experiencing them at an unacceptable rate). I do think they are related, based on what I’ve seen so far.

jasonnutter on Oct 18, 2019

@AndrewCraswell As a workaround, can you try setting navigateToLoginRequestUrl: false?

jasonnutter on Oct 9, 2019