Repository navigation
Tunneling: Improve JavaScript SDK API #14248
Description
Activity
I'm loving the way the next.js SDK is setting this up, now I have to implement a custom route for tunnelling.
The following setup works for the arc browser. (think it uses uBlock under the hood)
/routes/monitoring/+server.ts
import { PUBLIC_SENTRY_DSN } from '$env/static/public'; import { json } from '@sveltejs/kit'; export async function POST({ request }) { try { const serverDSN = parseDSN(PUBLIC_SENTRY_DSN); const envelopeBytes = await request.arrayBuffer(); const envelope = new TextDecoder().decode(envelopeBytes); const piece = envelope.split("\n")[0]; const header = JSON.parse(piece); const dsn = new URL(header["dsn"]); const project_id = dsn.pathname?.replace("/", ""); if (dsn.hostname !== serverDSN.host) { throw new Error(`Invalid sentry hostname: ${dsn.hostname}`); } if (!project_id || !serverDSN.projectIDs.includes(project_id)) { throw new Error(`Invalid sentry project id: ${project_id}`); } const upstream_sentry_url = `https://${serverDSN.host}/api/${project_id}/envelope/`; await fetch(upstream_sentry_url, { method: "POST", body: envelopeBytes, }); return json({}, { status: 200 }); } catch (e) { console.error("error tunneling to sentry", e); return json({ error: "error tunneling to sentry" }, { status: 500 }); } } function parseDSN(dsn: string) { const url = new URL(dsn); const id = url.pathname?.replace("/", ""); return { host: url.hostname, projectIDs: [id] }; }
hooks.client.ts:
Sentry.init({ enabled: PUBLIC_SENTRY_ENABLED === 'true', dsn: PUBLIC_SENTRY_DSN, environment: PUBLIC_SENTRY_ENVIRONMENT, tunnel: '/monitoring', });
- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Dec 30, 2024 Can we detect in our SDKs if an ad blocker blocks our requests? If yes, we could try to send the data first directly to Sentry, and if it doesn't work, use the tunnel.
This would be a rather drastic behaviour change. I can see users using tunneling to not just proxy requests but actually mutate events (e.g. scrub data with some custom logic). Not saying they should do that but just putting it out there that this likely exists in one form or another. So if we do this, I'd rather do it in a major only and with according migration docs.
Description
ref https://github.com/getsentry/projects/issues/385 and https://www.notion.so/sentry/Project-Improve-Tunneling-1368b10e4b5d80b38557c66fbcf6d8a1
Right now there is a singular option for
tunnelinSentry.initthat you pass in to enable tunneling. This makes setup very simple, which is a positive, but it has drawbacks.To address this, we should improve the tunneling API within the Sentry SDKs
Investigate
Explore
tunneltransport rather than top leveltunneloption #14152 raises a custom transport, but perhaps an integration also works well.Implement
With that approach, we take most of our load from our user's infrastructure. Furthermore, we could identify how much data comes through the tunnel and how much directly via Sentry when adding metadata to the tunneled envelopes. We could also share that data with our users.