auth0 / auth0-oidc-client-net

OIDC Client for .NET Desktop and Mobile applications
https://auth0.github.io/auth0-oidc-client-net/
Apache License 2.0
84 stars 48 forks source link

Allow environment override for WebView2 #321

Closed TinaBasinger closed 6 months ago

TinaBasinger commented 7 months ago

Checklist

Describe the problem you'd like to have solved

We are using your Auth0.OidcClient.Winforms package in a program that we are installing to the Program Files folder. By default, the WebView2 control will create a folder beside the calling application. This does not work well in the Program Files folder due to permissions. To work around this, the WebView2 object needs created with an environment set for the user's AppData folder.

Describe the ideal solution

The WebViewBrowser class should have an optional way to provide a WebView2 environment.

Alternatives and current workarounds

We have worked around this by creating a custom Browser class for the specific reason to add 2 lines of code. Inside InvokeAsync, where your class creates the WebView2 object, we add these 2 additional lines:

CoreWebView2Environment cwv2Environment = await CoreWebView2Environment.CreateAsync(null, Application.LocalUserAppDataPath, null); await webView.EnsureCoreWebView2Async(cwv2Environment);

This works, but it's terribly inefficient to create our own class for those 2 lines. It also means that we'll miss out on future changes to the default WevViewBrowser that you provide. As this use case seems like it would be a common scenario (installing and running from Program Files), it'd be helpful to many developers to provide some options around the WebView2 functionality.

Additional context

No response

frederikprijck commented 6 months ago

This works, but it's terribly inefficient to create our own class for those 2 lines. It also means that we'll miss out on future changes to the default WevViewBrowser that you provide

We typically make very little changes to the Browsers. So I'd argue the implementation you have is fine and also what we recommend in situations like this.

As this use case seems like it would be a common scenario

This is the first report of this, so not sure how common it is. Let's gather feedback and see if the need comes up.

Closing for now, as the recommendation is to roll your own browser implementation if ours does not work for your use-case.

However, if you feel strong about this, I am happy to review, merge and release a PR that adds an optional CoreWebView2Environment to the constructor of the browser, in both WPF and Winforms, but this is not something we plan to prioritise working on ourselves given the workaround available.