Configuration to allow CORS with OTLP HTTP

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Someone writing a rich browser app, e.g. React, might want to send telemetry via OTLP HTTP to the dashboard. The dashboard supports OTLP HTTP, but standard browser security blocks post requests from the browser app to the dashboard because they're hosted on different ports.

Describe the solution you'd like

Configuration to enable CORS for the dashboard's OTLP HTTP endpoints.

Additional context

No response

[aaronpowell]

I think it would make sense that when the dashboard is started with OTLP HTTP enabled, it should add the resources in the Aspire app as allowed hosts automatically by reading the endpoints they expose.

This would remove overhead from having to do manual configuration.

[samsp-msft]

To enable CORS we need to set a policy in the dashboard as to which sites we enable CORS for which will enable them to access the endpoints.

• There is the option to enable all sites to access the dashboard, but that most likely violates the security policy.
• The dashboard should take a list of base urls that it will add a CORS policy for.
  • This should be exposed as an environment variable that can be set when using the dashboard standalone
  • AppHost/DCP can pass the list of sites to the dashboard when it starts it

https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-8.0#set-the-allowed-origins

[aaronpowell]

To enable CORS we need to set a policy in the dashboard as to which sites we enable CORS for which will enable them to access the endpoints.

For local development, wouldn't it be best to have any running service configured by default?

Or are you more referring to when the dashboard is hosted in ACA? Does it make sense to have the dashboard as an Aspire component, maybe automatically registered as part of the DistributedApplication.CreateBuilder call (and exposed from the builder), that way you could make it more explicitly added to services.

[DamianEdwards]

The dashboard, whether running locally or in ACA, should be "secure by default", and IMO that includes not blindly accepting CORS requests from any domain. Doing so would allow any website you visit to send telemetry to the dashboard running locally. I agree with @samsp-msft that by default it should configure the CORS policy to be limited to the known addresses for resources running in the same AppHost instance, by way of the environment variable being default-configured as such when launching the dashboard via the AppHost. Supporting more configuration options when running the dashboard locally as part of AppHost is likely dependent on modeling the dashboard as a standard resource in the app model so it can be configured (either via high-level API or environment variable configuration).

[aaronpowell]

Sorry, when I said "any running service" I was meaning anything running in the same AppHost instance, not a policy of *.

If it became a configuration option, then could we have that exposed via the Bicep used to enable the dashboard in ACA? That way as part of deployment (either generated by the manifest or manually edited Bicep) it'd be possible to set the trusted domains.

[JamesNK]

Here is the work I think is required:

1. The dashboard has configuration options for allowing CORS on the OTLP HTTP endpoints. The configuration would set up a CORS policy that is used by the dashboard's OTLP HTTP endpoint.

   Example configuration (* is allow all, comma separated values allowed):

   • DASHBAORD__OTLP__CORS__ORIGINS=http://localhost:5000,https://localhost:5001
   • DASHBAORD__OTLP__CORS__HEADERS=*

   By default, CORS is disabled unless configured otherwise.
   There isn't CORS configuration for allowed HTTP methods. OTLP only uses POST so it is hardcoded.
   The OTLP gRPC endpoint doesn't use the CORS policy. gRPC doesn't work from the browser so there's no point.

2. Use the dashboard configuration to create the ASP.NET Cores policy and set it on the endpoint.

3. When the app host starts up, it automatically passes all resource http/http addresses to the dashboard as allowed CORS origins. All headers are allowed. IMO this is ok since these are resources that the user has configured and are part of their app. We already trust them to send the dashboard OTLP from the server (API key is set as an env var) so allowing CORS is fine.

End result:

• Sending telemetry from a SPA app in the local dev environment will just work.
• People using the standalone dashboard will have to configure CORS manually.

[JamesNK]

Prior art: jaegertracing/jaeger#4586

Jaeger (distributed tracing app and accepts OTLP) has configuration for CORS.

[DamianEdwards]

Note that we'll need to update the dashboard threat model to cover this new scenario.