Fix configuration binding

[drewnoakes]

The dashboard supports the use of client certificates for authorization to the resource service. This requires a custom resource server, and we're not aware of any that use this feature.

Throughout the Aspire documentation, we advertise values like Dashboard:ResourceServiceClient:ClientCertificate:Source to configure certificates, however these values will not bind to the documented configuration values. The CLR property was ClientCertificates (plural), not the documented ClientCertificate (singular).

This change makes the dashboard respect the documented configuration names.

We don't have any automated tests here yet. We have manual test instructions in #4626 for vendors to use, which assume this fix has been applied.

Microsoft Reviewers: Open in CodeFlow

[JamesNK]

Throughout the Aspire documentation, we advertise values like Dashboard:ResourceServiceClient:ClientCertificates:Source to configure certificates, however these values will not bind to the documented configuration values.

nit: Typo in the issue description. Dashboard:ResourceServiceClient:ClientCertificate:Source is what is in the docs.

[JamesNK]

I assume fixing #4626 involves creating integration tests?

[JamesNK]

An end-to-end test with client cert auth would be useful.

However, to simply test the configuration works as expected you could write an integration test like here:

aspire/tests/Aspire.Dashboard.Tests/Integration/FrontendBrowserTokenAuthTests.cs

Lines 31 to 36 in 02a0bc6

	await using var app = IntegrationTestHelpers.CreateDashboardWebApplication(_testOutputHelper, config =>
	{
	config[DashboardConfigNames.DashboardFrontendAuthModeName.ConfigKey] = FrontendAuthMode.BrowserToken.ToString();
	config[DashboardConfigNames.DashboardFrontendBrowserTokenName.ConfigKey] = apiKey;
	});
	await app.StartAsync();

The test passes the config value when the dashboard starts up, then gets the dashboard options from the running app and assert that the expected property is set on the options.

var options = app.DashboardOptionsMonitor.Value;
Assert.Equals("...", options.ResourceServiceClient.ClientCertificate.Source);

Consider doing adding the test in this PR or at least in an immediate follow up PR.

Edit: There is a whole file full of tests like these. Add it here: https://github.com/dotnet/aspire/blob/02a0bc6fef3f2353b306f3ada63445f3bf133b83/tests/Aspire.Dashboard.Tests/Integration/StartupTests.cs

[drewnoakes]

I assume fixing #4626 involves creating integration tests?

Ultimately, but for now Bala's team is going to do manual testing, following the steps outlined in #4626 (comment).

you could write an integration test like here

I added one, though it wouldn't have caught the bug this PR fixes.

[JamesNK]

I don't think you can say a test wouldn't have helped here. If the config key in the test didn't set data onto the options because of a bad property name, the test would have caught the bug. And having all the configs as constants in one place is useful when writing docs because you can double check config names in the docs against the config names in the list.

[drewnoakes]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).