You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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":"[email protected]/123"}
dsn
at all (remove it in the infrastructure which forwards and rewrites the request)The text was updated successfully, but these errors were encountered: