-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workaround for Blazor WASM to connect to Azure Cosmos with .NET 5 #26942
Comments
@ylr-research Could you please share the configuration of the |
public static async Task Main(string[] args)
{
var builder = WebAssemblyHostBuilder.CreateDefault(args);
builder.RootComponents.Add<App>("app");
builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
builder.Services.AddHttpClient();
builder.Services.AddSingleton<CosmosClient>(serviceProvider =>
{
IHttpClientFactory httpClientFactory = serviceProvider.GetRequiredService<IHttpClientFactory>();
CosmosClientOptions cosmosClientOptions = new CosmosClientOptions
{
HttpClientFactory = httpClientFactory.CreateClient,
ConnectionMode = ConnectionMode.Gateway
};
return new CosmosClient("<connectionstring>;", cosmosClientOptions);
});
builder.Services.AddLocalization(options => options.ResourcesPath = "Resources");
await builder.Build().RunAsync();
} |
@ylr-research Because Blazor WebAssembly apps are public clients that can't keep secrets you need to use resource tokens. @JeremyLikness wrote up a nice blog post on how to do this: https://blog.jeremylikness.com/blog/azure-ad-secured-serverless-cosmosdb-from-blazor-webassembly/. However, I don't think we've tested this setup with .NET 5 yet, but I believe it should work. Can you confirm whether you are using this approach and it if works for you? |
@danroth27 I'm not using his approach. I'll give it a try now with RC2 and let you know how it goes. |
@danroth27, I do have a question though. How was it working before, when the APIs were Mono based? I used to just add a AzureCosmos nuget package, register a client and everything worked. Blazor WASM can't keep a secret now neither before. Most importantly, it is my understanding this issue is to be resolved with .NET 6 wave. Would that means I won't need to follow the above approach and keep doing it as before? |
For Blazor WebAssembly 3.2 we shipped the Mono implementations of the crypto APIs. So if you tried to use HMAC with 3.2 it would work. However, using HMAC means you need to have access to a secret key, which there is no way to protect in a public client app like a browser app. So it worked, but it would expose the key. I'm guessing the key is embedded in the connection string? In .NET 5, as part of unifying on the .NET 5 framework libraries, we had to remove the crypto implementations because of issues with being able to service them. We generally prefer to rely on the platform crypto implementations, which get serviced with the platform. Browsers do surface crypto support, but in a form that doesn't match well with the .NET crypto APIs. That's what we're planning to address in .NET 6. With .NET 5 you need to access the browser's crypto support through JS interop. But even with crypto support coming back in .NET 6, there still won't be a safe way to store a secret in the browser, so generating HMACs still won't be recommended. The approach using resource tokens will still be the preferred approach. |
Fair enough. Thanks for your prompt response. |
This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes. See our Issue Management Policies for more information. |
Hi @danroth27. I have a vanilla Blazor WASM (standalone) app which basically as I type autocompletes results from Azure CosmosDB. The Autocomplete razor file is a modified version of the one here. After upgrading to .NET 5 PNS exception started to be thrown (see #26450).
Autocomplete.razor
AutocompleteProductItem
Index.razor
ViewProduct.razor
The text was updated successfully, but these errors were encountered: