feat(core): Add tunnel server helper

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892

[timfish]

Closes#13453 and gives a simpler path for #10309 and adding tunnel support to other frameworks.

The current tunnel troubleshooting docs suggest this code but it doesn't work with binary envelopes so breaks with compressed replay envelopes and attachments.

constSENTRY_HOST="oXXXXXX.ingest.sentry.io";constSENTRY_PROJECT_IDS=["123456"];exportconstpostAction=async({ request })=>{try{constenvelopeBytes=awaitreq.arrayBuffer();constenvelope=newTextDecoder().decode(envelopeBytes);constpiece=envelope.split("\n")[0];constheader=JSON.parse(piece);constdsn=newURL(header["dsn"]);constproject_id=dsn.pathname?.replace("/","");if(dsn.hostname!==SENTRY_HOST){thrownewError(`Invalid sentry hostname: ${dsn.hostname}`);}if(!project_id||!SENTRY_PROJECT_IDS.includes(project_id)){thrownewError(`Invalid sentry project id: ${project_id}`);}constupstream_sentry_url=`https://${SENTRY_HOST}/api/${project_id}/envelope/`;awaitfetch(upstream_sentry_url,{method: "POST",body: envelopeBytes,});returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

Rather than get users to parse their own envelopes for this info, this PR adds a handleTunnelEnvelope function to @sentry/core which handles all the logic for forwarding envelopes.

If your client DSN is the same as your server DSN, the above example code becomes:

exportconstpostAction=async({ request })=>{try{awaithandleTunnelEnvelope(awaitrequest.arrayBuffer());returnjson({},{status: 200});}catch(e){console.error("error tunneling to sentry",e);returnjson({error: "error tunneling to sentry"},{status: 500});}};

If you want to forward envelopes for other DSNs, you can just pass an array as dsnAllowList in the options. Not sure about this naming. Is allowedDsns better?

We can further wrap the handleTunnelEnvelope function and expose more complete examples for each framework. For example we could expose a helper which takes a Request and returns a Response or export an API route ready to use.

[mydea]

I like it! IMHO it is not that easy to handle envelopes (since replay), so it's nice if we can provide this to users instead of asking everybody to re-implement this.

[timfish]

The envelope parsing utils are also all in @sentry/utils which isn't part of our public API and could technically change between minor versions.

[mydea]

@AbhiPrasad & @timfish should we revive and merge this? I think it would be nice still!

[timfish]

A few weeks ago Abhi said to wait on this for now because we have other general tunnelling improvements planned.

[AbhiPrasad]

Yup. After I get the initial logs stuff merged in for the JS SDK, I think we can take a look at this in detail.

[JPeer264]

@timfish@AbhiPrasad any updates on this?

[github-actions]

This pull request has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you apply the label PR: no-auto-close I will leave it alone ... forever!

[timfish]

Closing in favour of #18892