[Bug]: Redirect after Azure Entra Login fails
Version
1.42.0
Steps to reproduce
- Create a Blazor Server app with activated azure ad authentication as described here
- Record a login
- On the step after Don't show this again window successfully closed and click on yes await the redirect and it will fail with the message ERR_INVALID_URL
- On a page reload the page is served as expected
Expected behavior
Redirect to the expected page like in version 1.41.2
Actual behavior
Redirect fails with the message ERR_INVALID_URL
Additional context
Videos of the behavior can be sent in private if helpful.
Environment
System:
OS: Windows 11 10.0.22631
CPU: (16) x64 Intel(R) Core(TM) i7-10875H CPU @ 2.30GHz
Memory: 32.90 GB / 63.72 GB
Binaries:
Node: 18.18.0 - C:\Program Files\nodejs\node.EXE
npm: 9.8.1 - C:\Program Files\nodejs\npm.CMD
IDEs:
VSCode: 1.87.0 - ~\Programs\Microsoft VS Code\bin\code.CMD
Look like an issue with the Chromium binary. It was working for me until I upgrade playwright and run playwright install command again. I saw the upgrade of the browsers binaries then it stop working.
I have a similar flow login with Auth0 instead of Azure.
after my e2e user login I'm getting redirected to my page and the browser crash with the same ERR_INVALID_URL
I was able to rollback to a previous version of playwright and make it work.
try to lock your version to "@playwright/test": "1.41.2",
First, uninstall your current browser binaries
yarn playwright uninstall
remove your node_modules and reinstall everything
yarn
yarn playwright install
my binary got rollback too.
du -hs ~/Library/Caches/ms-playwright/*
399M /Users/..../Library/Caches/ms-playwright/chromium-1105
# To the old locked version of "@playwright/test": "1.41.2",
du -hs ~/Library/Caches/ms-playwright/*
389M /Users/..../Library/Caches/ms-playwright/chromium-1097
Yes, I did the same today, except i'm on .NET. But for future releases it should be fixed to be able to stay up to date with all releases and patches.
While the reproduction is not self-contained and looks involved to us in order to reproduce, it looks very much like that this is an upstream Chromium bug. In order to investigate more about it, I recommend the following steps:
- Try channel: "chrome-canary"
- Try channel: "chrome-dev"
- Try channel: "chrome-beta"
- Try channel: "chrome"
You can pass the Channel when launching the browser or in the playwright.config.ts when using Node.js or via the runsettings file in .NET.
This would help us to understand which versions of Google Chrome are affected, maybe they already fixed it.
Same issue
Started happening after upgrade Playwright to 1.42.0
- Login with Azure Entra with Microsoft Identity (from MVC application Net8)
- Reach the 'Stay logged in' question, and click Yes
- Receive from signin-oidc a net:ERR_INVALID_REDIRECT error, then net:ERR_INVALID_URL.
- (If you just refresh the agent page when not running headless, the page loads fine)
Hello @mxschmitt,
sorry for the delay, it took me some days to find the time to test it. The results as following:
- Try channel: "chrome-canary"
- Working
- Version: Version 124.0.6367.0 (Offizieller Build) canary (64-Bit)
- Try channel: "chrome-dev"
- Working
- Version: Version 124.0.6356.6 (Offizieller Build) dev (64-Bit)
- Try channel: "chrome-beta"
- Working
- Version: Version 123.0.6312.46 (Offizieller Build) beta (64-Bit)
- Try channel: "chrome"
- Working
- Version: Version 122.0.6261.129 (Offizieller Build) (64-Bit)
- No Channel - Chromium
- Not Working
- Version: Version 123.0.6312.4 (Entwickler-Build) (64-Bit)
If you need additional informations let me know.
Best regards
Marcus
Thats already helpful! So it might be that it was fixed between 123.0.6312.4 and 123.0.6312.46.
If you are using Node.js, you can try our Beta which contains 123.0.6312.22 - so a little bit newer as well. In the meantime I'd recommend using the chrome-beta channel or waiting for the next Playwright release which will contain Chromium 124.
Hello @mxschmitt,
I will stay at version 0.14.2 and wait for an update to avoid an installation of the beta on the build server.
Is it possible to get an information if this should be fixed? I would test it afterwards.
Best regards
Marcus
Would it be possible to share a reproduction which does not require setting up AD auth etc.? (feel free to ping me on Discord if you have something to share) - then we can find out which exact upstream patch broke it for future reference, otherwise we sit more in the dark. Thank you.
I can't imagine how because the error seems to be azure ad authentication specific. :/
This might be fixed in the latest Canary, could you try reproducing it there? https://playwright.dev/docs/canary-releases
How could i test it under .net?
Its a little bit more complex:
- Download https://playwright.azureedge.net/builds/chromium/1110/chromium-win64.zip
- Extract it somewhere
- Point the ExecutablePath when launching the Browser towards the
chrome.exe - If you are using Microsoft.Playwright.NUnit/MSTest, you can set:
<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
<Playwright>
<BrowserName>chromium</BrowserName>
<LaunchOptions>
<ExecutablePath>...</ExecutablePath>
</LaunchOptions>
</Playwright>
</RunSettings>
@mxschmitt I had the same issues, using "Azure AD B2C", Playwright tests suddenly started to fail in my auth setup, when upgrading from 1.41.2 to 1.42.1, due to Error: page.waitForNavigation: net::ERR_INVALID_URL (yes, I will stop using waitForNavigation soon 😉) for both "Desktop Chrome" and "Desktop Firefox".
I can confirm that using next and specifically the below versions "fixes" the issue for me for both "Desktop Chrome" and "Desktop Firefox" :
@playwright/test 1.43.0-alpha-2024-03-25
playwright 1.43.0-alpha-2024-03-25
Due to the nature of auth, I am too unable to submit a programmatic reproduction. But what I am doing is something like this to setup/persist auth for the test suite:
const browser = await chromium.launch();
const page = await browser.newPage({ ignoreHTTPSErrors });
await page.goto(baseURL!);
await page.fill(
"[placeholder='Email Address']",
FOO_USER_EMAIL!,
);
await page.fill("[placeholder='Password']", FOO_USER_PASSWORD!);
await Promise.all([
page.waitForNavigation(), <--- FAIL LIVES HERE
page.click("button:has-text('Sign in')"),
]);
await page.context().storageState({ path: storageState as string });
await browser.close();
Thanks for the confirmation! I'll close it for now, since we know that the issue has been fixed in our beta version and there is no action item on our side. This bugfix will get included in our next release. As a workaround for now we recommend the canary/beta release.
Good to hear @max-schaefer
Did you find a way to catch this in your own regression tests for PW? Could you point me to what change in 1.43 that fixes this issue?
Closing this ticket before the fix was out sure made this harder to figure out there is an ongoing issue with the latest version.