Testcafe: Does not render the application when using MSAL for login.

[zsid]

What is your Test Scenario?

I am replacing react-adal to react-aad-msal. Cannot see the application rendered once I have logged in.

What is the Current behavior?

Does not render my application in tests

What is the Expected behavior?

Renders my application in tests

What is your web application and your TestCafe test code?

I have created a repo with instructions how it can be replicated - https://github.com/zsid/testcafe-azure-ad

[zsid]

I have previously raised a bug for having a loop when logging in with react adal. Might be a good point for reference on how to set up Azure as the problem was solved then - https://github.com/DevExpress/testcafe/issues/4024

[AlexKamaev]

I was able to reproduce the issue. I confirm that without TestCafe, the app works and with TestCafe - there is a blank page.

Could you please clarify whether you have problems only if you use the react-adal module?
Do you still have problems with the login loop?

[zsid]

@AlexKamaev, --disable-page-caching has fixed the issue with react-adal module.

However, we are moving away from react-adal and using msal and react-aad-msal. Please let me know how we can run our tests when using react-aad-msal

[zsid]

The reason we are moving away is adal js is not being support anymore and they are advising people to move to react-aad-msal more info in this issue https://github.com/AzureAD/azure-activedirectory-library-for-js/issues/772.

I dont know if the login loop problem will be present once we move to react-aad-msal. Needs to be tested once the app is rendering

[AlexKamaev]

At this moment it's difficult to say why your scenario stopped working. We need to research it in detail.

[zsid]

Good morning @AlexKamaev. Would you be able to suggest a work around to make the tests run until a fix is ready - our e2e tests are blocked at the moment as we cannot authenticate

[AlexSkorkin]

We don't have a workaround for this behavior yet.

[zsid]

Hey @AlexSkorkin, how is the plan going to address this bug?

[arubtsov]

Hi @zsid,

we cannot provide any estimates at this time.

[kerosan]

hello, I have example of application which successfully logging in user on localhost npm start https://codesandbox.io/s/interesting-roentgen-7vntv
our team shared some credentials and now we can reproduce bug by running npm run testcafe

please try to reproduce it locally (not in codesandbox.io) and make some resolution
// test credentials:
// [email protected]
// AaaAaaQqq123
// OR you can register your own user by clicking registeron microsoft login form

[LavrovArtem]

@kerosan, Thank you for the additional information.

[maximkoev]

Is there any ETA bug fix?

[miherlosev]

@maximkoev

We don't have ETA for this bug. Once we have news to report, we will notify you here.

[kerosan]

there is new versions may fix this bug:
"react-aad-msal": "^2.3.5",
"msal": "^1.3.0",
https://github.com/syncweek-react-aad/react-aad/issues/218
need to double check

[AlexKamaev]

@kerosan
Thank you for additional information. I hope these new versions will help you resolve the issue. However, we still need to research this behavior.

[evansabove]

I'm the original logger of #4754 and the latest version of msal (1.3.0) has also resolved this for me. Thanks for your time investigating.

[AlexSkorkin]

@evansabove, thank you for sharing your findings with us.

[taruntomar-qa]

Hi All,

I am also facing same issue as mentioned in the thread..

In my organization, We use Azure AD authentication for our Web application.
This is how flow happens :-
a. I pass Azure AD enable url to the Testcafe test of my web application.
b. It goes to the Microsoft site (https://login.microsoftonline.com/) and requires me to Enter - my email ID.
c. The it hits the cloudfed endpoint of my organization and does the SSO authentication
d. It returns the Url along with the Token_ID in the browser
e. Displays a Blank page and message in console - "Login_In_Progress: Error during Login call - login is already in progress. "

This seems to be a show stopper as testcafe is not redirecting to the Web application even after authentication.

Please respond !!

[wentwrong]

@taruntomar-qa,
Thank you for the report. Unfortunately, we don't have any workaround yet, but we are working on it. We'll update the thread once we have more information to share.

[aviita]

Also seing issues on testing our React SPA app with MSAL.js authentication. I am evaluating TestCafe for providing end-to-end application. We are using Azure AD B2C as the authentication provider.

We have a automatic redirect to the login page and also endup into infinite loop, so pretty similar to #4754, but we are using msal.js version 1.4.0 and seing this problem. We have our own implementation of getting the MSAL to work with react app instead of using react-aad-msal.

If needed I could provide another example to reproduce the issue with, I think.

[aviita]

I could also provide some more details after a quick study. I am not very deep into the way MSAL.js works, but can maybe provide some insight.

Firstly we are using the implicit grant flow (the only one Azure AD B2C works with currently) and that still locks us down to MSAL.js 1.x instead of the new 2.0.

Getting the authentication to work with MSAL.js without problems was quite a hassle, but some help from Microsoft and looking into the github issues got us past those (when running manually).

So first of all the implicit grant flow seems to rely on page being redirected to the redirect address usually being the same as the SPA app it self and the MSAL.js somehow picks up the details of the authenctication from the URL params. To me it seems that currently that phase is failing as after the redirect I am not seeing the access token as I am supposed to.

So what doest TestCafe do in this case? Also while I do not understand the tricks TestCafe does to make things work, I would also like to note that if Azure B2C is not able to mathc redirect URL being configured (e.g. https://localhost:3000/authRedirect) to the list of approved redirect urls configured to it, then it resorts to redirecting to one of the URL's on its approved list it seems.
And so also what is TestCafe doing to even handle these redirects to keep browser on the TestCafe page (prefixed e.g. with http://192.168.1.234:33381/igBR4h5Jb*7eKBawbAF!f/)?

[aviita]

It seems that with TestCafe anything relying on window.location regarding those redirects cannot work regarding the Azure AD B2C redirect address as it needs to be configured to address allowed in Azure AD B2C and that call always return the testcafe test address.

Also relying on window.location.pathname seems like it could not work. Trying to achieve trick mentioned in MSAL.js issue 1199, but without use of plain html site (see react-aad-msal dock) and instead the AAD address and detecting the path name. But starting to wonder if that plain HTML site would work any better with TestCafe.

[arubtsov]

Hello @aviita,

Thank you for reaching out to us.

And so also what is TestCafe doing to even handle these redirects...

TestCafe modifies DOM and prefixes URLs with a service part. Requests are then proxied by hammerhead.

It seems that with TestCafe anything relying on window.location regarding those redirects cannot work

With TestCafe your application should interact with a browser API the same way as without it, i.e., you can rely on window.location.
Can you check if your application loads under TestCafe with MSAL.js v1.3.0? Please take a look at this comment and check if the solution described there works for you. An example is always welcome.

[aviita]

Ok. I will check the 1.3.0, but I did check 1.3.4 already actually with no difference in behaviour.

In the meantime I noticed that there had been another update to MSAL.js and a followup bug (2370) on that, so yes the MSAL.js is not all that robust in it self. That is why I am so happy it is finally working withuout issues (in regular use). So while the MSAL.js is bit shaky it is the pricing model and other features Azure AD B2C that makes it such a good fit for us that there is currenly no way to back out from that. That is why we might go with another testing tool, we can be sure does not get into trouble with the auth setup.

Anyways I would like to assist in fixing this issue, here is a github gist with the auth code that shares the logic the app works with in regards to this authentication. Note that code in it self does not comile as such, since e.g. the StaticAsset defined by NSwag based on our REST API is missing. Also if you want to reproduce this, can you setup your own Azure B2C tenant or do you need help in that regard? One needs to have the application (in B2C) configured for SPA app with implicit grant flow to make this code work. Additionally as code comments show there needs to be this one scope configured for Read.All.

[arubtsov]

@aviita, Thank you for your assistance. We will look into the example you shared. I would like to one more time draw your attention to this solution), which may help you resolve the issue.

[aviita]

@arubtsov, I guess I forgot to mention that I did run all my test runs with node --max-http-header-size=1024000, so that did not help to resolve the issue. It may be though that we will select another end-to-end testing tool in the end to ensure the authentication does not come an issue for us. In the meantime I can try to provide more information to solve this issue if need be.

[aleks-pro]

Thank you for the additional information. We started to research the issue, however, we cannot give any estimates on this.

I can try to provide more information to solve this issue if need be

Thank you for the cooperation. We will let you know if we need further assistance.

[Ogurecher]

We researched the issue and are working on a fix.

For the team:
This issue is caused by an incorrect interaction with the msal library, which uses redirects for authentication and partially clears sessionStorage between the beforeunload and unload events.

Storage wrappers (for localStorage and sessionStorage) don't save changes in native storages if these changes take place after the beforeunload event. This means that changes that are applied between the beforeunload event and the moment the page is closed are discarded and won't be available after the redirect.

msal's behavior depends on the content of sessionStorage. When sessionStorage is not updated correctly, msal behaves differently. In this case, the user is not considered authorized, and react-aad-msal does not render the page.