Automated Chromium-based tests with Authentication redirect from MSAL(Angular)

Viewed 132

I'm looking at doing a short proof of concept, validating 2 different UI end to end testing frameworks against each other using an internal project at work.

My project is an Angular based application, which has a login page, which is managed by MSAL for Angular(1) library. The standard flow of a user is:

  1. Navigate website URL (/login)
  2. Press Login Button
  3. User is redirected to an Azure B2C Login Page
  4. User inputs Username/Password clicks "Login"
  5. Azure B2C redirects the user to the Login page, which has a subscription the broadcast channel for the event "msal:loginSuccess"
  6. Once an event has been received the application makes a few API requests(now that the user is authenticated), and then redirects the user to the applications dashboard page (/dashboard)

This application has been running for a few years now and we don't have any issues with authentication manually. But as we started to look both at these testing frameworks as part of the POC, we started to notice an issue where by when the browser is redirected back to the login page(step 5), the broadcast event is either not being triggered, or captured(we still need to determine this). As a result the tests fail to continue, as the browser is waiting to be notified that the user is now authenticated - Theres no way to progress on from here.

If we use Firefox as our browser for Playwright(not tried Firefox in WebdriverIO yet), the tests run without issue, the user logs in, and is redirected successfully, it appears the issue is only happening with Chromium based browsers(we've tried Edge as well) from what we've seen so far.

I've googled but not found anything that might help, and getting fairly stuck in how we progress from here with the proof of concept as the request was to use Chrome not Firefox(larger user base for our application). We could spin up a test version of the application with some debug statements to confirm the event is not triggered, but that might come out of our scope, and extend the window we have...

We've tried a few chrome arguments like headless and incognito(in WebdriverIO, I believe Chrome is already incognito in Playwright) - I think it has to be something like this since the tests run in Firefox, but not sure where to start with these, as there looks to be a lot of possible arguments: https://peter.sh/experiments/chromium-command-line-switches/

Are there any recommendations, for this type of use case?

0 Answers
Related