Microsoft-authentication-library-for-dotnet: [Bug] WebView2-based embedded browser does not work in protected directories

[mjcheetham]

Which Version of MSAL are you using ?
MSAL 4.28.2

Platform
net5-windows10.0.17763.0

What authentication flow has the issue?

• Desktop / Mobile
  
  
  
  • [x] Interactive
  
  

Is this a new or existing app?
This is an existing app attempting to adopt new feature.

Repro

1. Install the "evergreen" WebView2 runtime
2. Create a .NET 5 console app with the following code

var pca = PublicClientApplicationBuilder.Create(clientId).Build();
var result = await pca.AcquireTokenInteractive(scopes)
   .WithUseEmbeddedWebView(true)
   .ExecuteAsync();

1. dotnet publish -r win-x86 the application and copy the publish output in to a directory like %ProgramFiles% (one that requires admin permission to create a new folder).
2. Run the console app from the new location.

Expected behavior
An embedded WebView2-based browser window appears asking for sign-in.

Actual behavior
An empty WinForms dialog appears. There are no errors.

Possible Solution
Set the WebView2 runtime environment to point the user data folder outside of the protected directory.
https://docs.microsoft.com/en-gb/microsoft-edge/webview2/concepts/userdatafolder

Additional context/ Logs / Screenshots
The folder the WebView2 runtime tries to create a user data directory, for the browser profile information (cookies, etc).
Moving the executable outside of a protected directory (where non-admin users have write and modify permissions) allows the WebView2 runtime to work.

[luismiguelsanchezGL]

I got exactly the same issue but using a WPF .NET Core 3.1 application and the Visual Studio Setup project to create an installer (setup.exe)

PublicClientApplicationBuilder.Create(ClientId)
                .WithB2CAuthority(AuthoritySignUpSignIn)
                .WithRedirectUri(RedirectUri)
                .WithDesktopFeatures()

Then, when calling the AcquireTokenInteractive

await app.AcquireTokenInteractive(ApiScopes).ExecuteAsync();

I dont get any error, but if I run the app as administrador I receive the following error

_Microsoft Edge can't read and write to its data directory._ %ProgramFiles%

I was reviewing the code to see if you guys were implementing the UserDataFolder property but I could not find it but I noticed that in the WinFormsPanelWithWebView2.csin the line number 68 you were creating a new instance of the CoreWebView2CreationProperties which has the UseDataFolder property but it is not been used.

[bgavrilMS]

Thanks for feedback, will take a look soon.

[bgavrilMS]

Let's try to not expose another property for now, but if we need to, we have options here:
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/504fb3507ab2968ababecceb5474ed7cadb34176/src/client/Microsoft.Identity.Client/ApiConfig/EmbeddedWebViewOptions.cs#L21

[mjcheetham]

Let's try to not expose another property for now,

IMO a good solution would be to either a) try and use the same directory as the installed Edge browser (if available), or b) pick a location in $HOME/%UserProfile%, like ~/.msal/webview2/data or similar.

This would mean all MSAL WebView2 instances (evergreen or fixed) share the same data directory. This is the same as with "WebView1" which shares the user's main Internet Explorer settings IIRC.

[trwalke]

@mjcheetham Just got this scenario working. will be in next release. 4.30.0

[FreddyD-GH]

@trwalke Sorry for being late to the conversation, but I feel that it's important for packaged apps to store their app data within the %LocalAppData%\Packages\xxxxxxxxxxxx folder. Makes it much easier for clean install/uninstall, and enforces app isolation. Unless there is some magic to direct %UserProfile% in packaged apps (which there could be, but it didn't seem so in my preliminary tests), it's not going to get stored in the appropriate place if an app uses APPX/MSIX packaging.

My preference to fix it would be one of the following:

• _(most preferred)_ Make the WebView2WebUi extendable without having to fork the entire repo, or have some extendable version of it that can be easily passed to .WithCustomWebUi()
• Make the user data folder customizable (i.e. a property of EmbeddedWebViewOptions)
• _(least preferred, but acceptable)_ Handle the special case of detecting if the app is running with packaged identity and use a subfolder of %LocalAppData%\Packages\xxxxxxxxxxxx instead of %UserProfile%

[trwalke]

@FreddyD-GH as we are trying to avoid adding additional api for this at the moment but I will try using %LocalAppData%\Packages\xxxxxxxxxxxx. Makes sense to enforce isolation and clean uninstallation

@bgavrilMS do you think we can create a separate feature request for this api?

[bgavrilMS]

We can definitely improve our existing sample around CustomWebUi, as the current one is a bit pointless:

https://github.com/Azure-Samples/ms-identity-dotnet-desktop-tutorial/tree/master/3-CustomWebUI/3-2-CustomBrowser

[jmprieur]

I used to be, historically when there was no other choice for .NET Core?
But yes. We also need to update the docs.ms page: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-acquire-token?tabs=dotnet#acquire-a-token-interactively

[bgavrilMS]

Ideally WebView2 SDK would give a good default, and @trwalke is starting a conversation with the team behind it on this.

We want to do the right thing out of the box, so as @FreddyD-GH suggested, we need to detect if the app is msix or not. We can use the logic here to do that - https://github.com/qmatteoq/DesktopBridgeHelpers/blob/master/DesktopBridge.Helpers/Helpers.cs

[sakkumarfirstam]

Hi Team,
May I know when will be the official release of 4.30? This is for accessing Microsoft Edge read and write to its data directory %ProgramFiles%.

Thanks
Kishan

[jmprieur]

@sakkumarfirstam : we'd want to release it this week.

[bgavrilMS]

Also, we've discussed with the WebView2 SDK folks and they are actively working on a solution "out of the box". So in MSAL 4.30 we will be setting the UserFolder out of program files and when WebView2 SDK finish up their work (no ETA, but work is in progress), we would upgrade as well.

[pmaytak]

This is included in MSAL 4.30.0 release.

cc: @mjcheetham @sakkumarfirstam @luismiguelsanchezGL @FreddyD-GH