Closed JamesNK closed 4 weeks ago
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.
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.
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.
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).
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.
Here is the work I think is required:
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.
End result:
Prior art: https://github.com/jaegertracing/jaeger/pull/4586
Jaeger (distributed tracing app and accepts OTLP) has configuration for CORS.
Note that we'll need to update the dashboard threat model to cover this new scenario.
How to add CORS, but with the configuration inside Aspire ?
Is there an existing issue for this?
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