Add CORS allowed origins config override to app host

[JamesNK]

Description

The dashboard supports OTLP HTTP and CORS to get telemetry from browser apps. CORS allowed origins are automatically calculated based on resource endpoints.

However, there are some scenarios where automatic CORS endpoints don't work:

• When browsing to the internal, proxy endpoint for a resource.
• When a custom domain is added to the host file and pointed to localhost, browsing to the custom domain.

These origins aren't automatically added and so sending telemetry fails.

The fix in this PR is to add manual dashboard CORS configuration to the app host. When the dashboard resource is configured, the app host manual configuration is simply forwarded to the dashboard. If there is no dashboard configuration then the existing logic is used.

Fixes #6249

Fixes customer bug with existing feature. Intended for 9.0.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

Microsoft Reviewers: Open in CodeFlow

[davidfowl]

This is a feature....

[JamesNK]

This is a feature....

Because it is a new config setting? IMO it's a bug fix for scenarios where browser telemetry feature doesn't work.

If it doesn't meet the bar then it can be moved to post 9.0.

[JamesNK]

@mitchdenny Can you take a look? The changes are all in the app host.

[mitchdenny]

Implementations wise I have no problem with this. The only thing that gives me pause is whether it might be better to have some kind of mechanism to add to the computed origins list rather than completely replacing it.

That said, I think that given this only impacts the OTLP endpoint means its probably not much of a security concern. After all most telemetry endpoints are fairly permissive anyway and this is still just locally bound.

We should probably mention this in the threat model?

[JamesNK]

The only thing that gives me pause is whether it might be better to have some kind of mechanism to add to the computed origins list rather than completely replacing it.

I think it is simplest to understand if it is a replace. That means setting DOTNET_DASHBOARD_CORS_ALLOWED_ORIGINS on the host is equivilent to setting DOTNET_DASHBOARD_CORS_ALLOWED_ORIGINS on the dashboard.

If it turns out we want a third option we could look at that as a different setting.

We should probably mention this in the threat model?

Sure