Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relay should not fail on invalid DSN in the header #3519

Open
Dav1dde opened this issue May 2, 2024 · 1 comment
Open

Relay should not fail on invalid DSN in the header #3519

Dav1dde opened this issue May 2, 2024 · 1 comment
Labels
filler Requires little effort to resolve. Ready to be picked up anytime.

Comments

@Dav1dde
Copy link
Member

Dav1dde commented May 2, 2024

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":"[email protected]/123"}

Workarounds:

  • Use a DSN Relay accepts: {"dsn":"[email protected]/123"}
  • Don't include the dsn at all (remove it in the infrastructure which forwards and rewrites the request)
@jjbayer
Copy link
Member

jjbayer commented May 6, 2024

  • Why do we have multiple ways of authenticating -> informs us on whether preferring one over the other is OK
  • Make sure if we prefer one then we overwrite the other.

@jjbayer jjbayer added the filler Requires little effort to resolve. Ready to be picked up anytime. label May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
filler Requires little effort to resolve. Ready to be picked up anytime.
Projects
None yet
Development

No branches or pull requests

2 participants