Customers may choose to use their own DSNs as described in the docs and send envelopes through their own infrastructure.
SDKs will embed the DSN into the envelope header.
If the customer's infrastructure wants to override the DSN via X-Sentry-Auth header Relay will still try to attempt to parse the valid DSN but with an invalid project key and project id in the envelope header and reject the envelope. If the envelope header did not include the DSN at all, Relay would accept the envelope.
Maybe Relay should treat structurally valid but with invalid project key (and id?) the same as if it was missing.
Example envelope header:
{"dsn":"foo@bar.relay/123"}
Workarounds:
Use a DSN Relay accepts: {"dsn":"00000000000000000000000000000000@bar.relay/123"}
Don't include the dsn at all (remove it in the infrastructure which forwards and rewrites the request)
Customers may choose to use their own DSNs as described in the docs and send envelopes through their own infrastructure.
SDKs will embed the DSN into the envelope header.
If the customer's infrastructure wants to override the DSN via
X-Sentry-Auth
header Relay will still try to attempt to parse the valid DSN but with an invalid project key and project id in the envelope header and reject the envelope. If the envelope header did not include the DSN at all, Relay would accept the envelope.Maybe Relay should treat structurally valid but with invalid project key (and id?) the same as if it was missing.
Example envelope header:
Workarounds:
{"dsn":"00000000000000000000000000000000@bar.relay/123"}
dsn
at all (remove it in the infrastructure which forwards and rewrites the request)