Document CORS settings for browser trace propagation

[danielkhan]

Problem Statement

As documented here, users need to configure Access-Control-Allow-Headers when the frontend and the backend are on different (sub) domains to allow trace propagation headers to be passed down with XHR requests.

Users may easily miss the docs and end up with a broken experience / spend much time trying to find the problem.

Solution Brainstorm

Here are two possible solutions:

1. Prominently link to the CORS documentation during setup. This would affect all backend platforms. Consider adding a snippet in an expandable section.
2. Automatically make all backend SDKs send these response headers - maybe guarded by a config option as part of the default init snippet.

[AbhiPrasad]

We cannot override how CORS headers are being set via the backend SDKs because this is a security concern. It can only be configured by users, so I think option 1 is the only viable solution here.

What we also need to make prominent is to make sentry-trace and baggage allow-listed as valid headers. Some people have strict nginx or apache configs that only allow a subset of headers through (our infrastructure at Sentry does this).

[getsantry[bot]]

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-sdks-web-frontend for triage ⏲️

[obecny]

we could warn users in "development" mode that the cors are not working properly and add information / link how to fix it and read more about it. This can be disabled then in production but in development the devs will see quickly and can do something about it. WDYT ?

[chargome]

@obecny how would you detect that in dev mode? The domains would probably differ from prod, e.g. everything could run on the same domain locally I think.

[obecny]

@obecny how would you detect that in dev mode? The domains would probably differ from prod, e.g. everything could run on the same domain locally I think.

function isLocalIpAddress(ipAddess) {
  // use regex to check if ip is from 10.x.x.x etc.
}
if (window.location.hostname === 'localhost' || window.location.hostname === '127.0.0.1' || isLocalIpAddress(window.location.hostname)) {
  // warn user
  console.log(.............
}

[chargome]

Oh so you would want to warn every user running locally – what I referred to was how to detect a potential cors issue in prod when users are running their services locally.

[obecny]

I would experiment then and do a monkey patching on fetch and XMLHTTPRequest (exactly as it was done with opentelemetry) and check there for errors. I believe we could then detect the cors errors and suggests the solution

[AbhiPrasad]

@obecny I think trying to identify network failures as CORS issues vs. actual errors gets unreliable, but if there is a way forward we can take a look. As far as I'm aware it doesn't work very well, so I don't think we should spend too much time on it.

CORS errors are purposefully sand boxed, but perhaps we can go to W3C and see if the browser vendors are open to an alternate instrumentation strategy?