Closed dotnetspark closed 4 years ago
@ylr-research Could you please share the configuration of the CosmosClient
?
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?
How was it working before, when the APIs were Mono based?
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