Avoid overwriting window.msal to support multiple providers for Azure B2C about microsoft-authentication-library-for-js

[Wozbo]

Hey just a note this is not fixed if you only pass the msal object back in the callback. The iframe generated to acquire a token silently will fail because it relies on the parent Windows msal object, and if you have multiple instances the token acquiring will not work because it tries to verify that the response matches your msal ID. This took forever to debut and fix; I can post a summary sometime soon to show which code points cause issues.

The long and short of it is that the msal object being tied to the window causes problems that we have to dance around.

[jmprieur]

Thanks @Wozbo. I believe this makes sense. We'll consider it for the backlog

[rohitnarula7176]

@Wozbo Can you try out my branch https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/rohitnarula7176/Issue_82 and let me know if it fixes the issue. With this change you can use 'this' inside the tokenRecievedCallback function to refer to the instance of the userAgentApplication as shown below:

var userAgentApplication = new Msal.UserAgentApplication(applicationConfig.clientID, null, authCallback);
        function authCallback(errorDesc, token, error, tokenType) {
            //This function is called after loginRedirect. Inside the function, this will refer to the userAgentApplication instance.
            if (token) {
                this.acquireTokenSilent(applicationConfig.graphScopes).then(function (accessToken) {
                    // Change button to Sign Out
                    updateUI();
                }, function (error) {
                    console.log(error);
                    this.acquireTokenPopup(applicationConfig.graphScopes).then(function (accessToken) {
                        updateUI();
                    }, function (error) {
                        console.log(error);
                    });
                });
            }
            else if (errorDesc || error) {
                console.log(error + ':' + errorDesc);
            }
        }

[Wozbo]

Hey, this looks pretty good! With this, is there any need for the window.msal object? Seems like a potential artifact that could be removed to not cause confusion.

[Wozbo]

Hey, I spoke too soon; this fails in an angular service because of the usage of 'this.' Is there any other solution that would be better and backward compatible?

[rohitnarula7176]

@Wozbo This is now fixed in dev. I have changed the code in a way that you do not need to rely on the window.msal object in the call back function passed in the constructor. You can just create an instance of userAgentApplication and use that instance in the authCallback. With this fix you can still use this.msal in the callback function as before and also use userAgentApplication instance to support multiple login types making it backwards compatible.

 var userAgentApplication = new Msal.UserAgentApplication(applicationConfig.clientID, null, authCallback, { cacheLocation: 'localStorage' });// cacheLocation defaults to sessionStorage if not set in the constructor
        function authCallback(errorDesc, token, error, tokenType) {
            //This function is called after loginRedirect. 
            if (token) {
                
            }
            else if (errorDesc || error) {
                console.log(error + ':' + errorDesc);
            }
        }