In a couple of builds [like this one](https://dev.azure.com/monacotools/Monaco/_build/results?buildId=305323&view=results) we have seen bad comparisons of `extension.js` in the Microsoft Auth extension:
> 2024-11-15T19:16:07.080Z electron-universal SHA for file Contents/Resources/app/extensions/microsoft-authentication/dist/extension.js does not match across builds a4db653e84d42a8cb4681a2274dffd34e0d7729cf14c0c4228b668778aa81c18!=6ff1bd8b8b51db2bff1d5f000625f0efe490a92eb282d0559aa904325d6cad68
Which is odd, considering there is no native dependencies used on macOS. The suspicion is that this is because of `keytar` which we have in the package.json using an odd `file:./path...`syntax to prevent it from installing normally since we don't use it.
The solution: additionally alias keytar in the webpack config so that the resolution is predictable.
* put copilot fix and explain in status bar
* fix up actions
* watch for execution error within the viewmodel
* make observable publicly readonly
* remove unused service
* fix tests
* remove unused import
This adopts the `NativeBrokerPlugin` provided by `@azure/msal-node-extensions` to provide the ability to use auth state from the OS, and show native auth dialogs instead of going to the browser.
This has several pieces:
* The adoption of the broker in the microsoft-authentication extension:
* Adding `NativeBrokerPlugin` to our PCAs
* Using the proposed handle API to pass the native window handle down to MSAL calls (btw, this API will change in a follow up PR)
* Adopting an AccountAccess layer to handle:
* giving the user control of which accounts VS Code uses
* an eventing layer so that auth state can be updated across multiple windows
* Getting the extension to build properly and only build what it really needs. This required several package.json/webpack hacks:
* Use a fake keytar since we don't use the feature in `@azure/msal-node-extensions` that uses keytar
* Use a fake dpapi layer since we don't use the feature in `@azure/msal-node-extensions` that uses it
* Ensure the msal runtime `.node` and `.dll` files are included in the bundle
* Get the VS Code build to allow a native node module in an extension: by having a list of native extensions that will be built in the "ci" part of the build - in other words when VS Code is building on the target platform
There are a couple of followups:
* Refactor the `handle` API to handle (heh) Auxiliary Windows https://github.com/microsoft/vscode/issues/233106
* Separate the call to `acquireTokenSilent` and `acquireTokenInteractive` and all the usage of this native node module into a separate process or maybe in Core... we'll see. Something to experiment with after we have something working. NEEDS FOLLOW UP ISSUE
Fixes https://github.com/microsoft/vscode/issues/229431
* wip
* move to auto provisioning, only cert based auth
* k
* missing compilation
* remove console logs
* extract get publish auth tokens, wait 5 seconds before polling for release
* Accept/Reject/Next/Previous actions per notebook
* Support Accept/Reject/Next/Prev in notebooks
* Nav through next/previous cells with changes
* revert
João Moreno
Daniel Imms
Tyler James Leonhardt
Joyce Er
Aaron Munger
LitoMore
Matt Bierner
Rob Lourens
Johannes Rieken
Henning Dieterichs
Ladislau Szomoru
Benjamin Pasero
Martin Aeschlimann
Don Jayamanne
Justin Chen