search

getsentry / sentry

Developer-first error tracking and performance monitoring
https://sentry.io
Other
39.17k stars 4.2k forks source link

Reporting-API (Reporting-Endpoints) support #38940

Open bkotsopoulossc opened 2 years ago

bkotsopoulossc commented 2 years ago

Problem Statement

Chrome 96 supports a new reporting API for CSP violations and other bad things. Is Sentry considering supporting this? Having a way to ingest and display these reports?

https://web.dev/reporting-api/

Solution Brainstorm

This could be similar to how sentry supports the report-uri directive, with the sentry.io/api/security/ endpoint

bkotsopoulossc commented 2 years ago

CC @bhollis

AbhiPrasad commented 2 years ago

Hey! We do support the Reporting API via ReportingObservers, but the headers sounds super interesting.

We already support a variety of headers for security reporting, and I think it would be good for us to support Reporting-Endpoints as well.

This requires changes to the Sentry product and Relay (our event ingestion system) - so I'll transfer this GH issue to that repo!

getsentry-release commented 2 years ago

Routing to @getsentry/ingest for triage. ⏲️

jjbayer commented 2 years ago

Thanks @bkotsopoulossc for reporting this! This does sound like something Sentry will support eventually. We will discuss it internally and get back to you.

bkotsopoulossc commented 2 years ago

That is awesome! I didn’t even realize the JS API existed. The main value I see with the header based API is for crashes. I imagine that if a browser tab crashes, it would be challenging for the browser to fire the report to a URL registered through JS. Even though the docs for the JS one mention supporting crashes, they say “and crash (although this last type usually isn't retrievable via a ReportingObserver”. Does that line up with what you’d expect as well?

AbhiPrasad commented 2 years ago

Does that line up with what you’d expect as well

Yup, crashes are probably the most useful thing we'd get here if we instrument this - it'll unlock a whole category of issues that previously weren't visible because we rely on JS to be running on the page.

For others who are following along, you can do this yourself while you wait for Sentry to build out a 1st class solution. You would:

  1. create a reporting API endpoint of yourself, easiest is probably a serverless function
  2. use a Sentry SDK with the sendEvent method that sends an event using our format (https://develop.sentry.dev/sdk/event-payloads/) to a Sentry project ...
  3. Profit

So you would try mapping the report API format -> a Sentry event, and then sending that Sentry event to Sentry!

bkotsopoulossc commented 2 years ago

I love that idea! We were thinking of building a custom UI to view these events that we infest on our server but sending right back to our sentry project sounds way better!

AbhiPrasad commented 2 years ago

Alright some additional context when we eventually take this on. Reporting-Endpoints is the v1 header for the reporting API, the legacy reporting API, v0, was named Report-To as per: https://web.dev/reporting-api-migration/

We probably want to skip out on using Report-To and move directly to Reporting-Endpoints, no need to support legacy.

There is also Network Error Logging, which isn't supported by Reporting-Endpoints but is by Report-To. As per:

To set up Network Error Logging for your site, you will need to use the legacy Reporting API that relies on the Report-To header. This is because the new Reporting API, that relies on the Reporting-Endpoints header, does not support Network Error Logging. Learn more in Browser support. Instead, a new mechanism for Network Error Logging will be developed in the future. Once that becomes available, switch from the legacy Reporting API to that new mechanism.

We can just wait till that new mechanism is decided and use that!

Some internal links for Sentry folks - sorry open source people this has Sentry Saas customer info so we can't share them publicly.

https://getsentry.atlassian.net/browse/FEEDBACK-251 - feedback ticket about Report-To

https://sentry.zendesk.com/agent/tickets/15696 - Report-To header https://sentry.zendesk.com/agent/tickets/18546 - report-uri deprecation https://sentry.zendesk.com/agent/tickets/22523 - Reporting API feedback

danielkhan commented 1 year ago

@AbhiPrasad and @smeubank please start product discovery and pick up the existing threads on this topic as well.

smeubank commented 1 year ago

excuse me while I post here some musings around CSP reporting and related :)

CSP has come up in a number of different places and I believe could stand for a more holistic approach to understanding the problem space and how best to surface them to users and enable devs to use more of Sentry to make CSP events more actionable. Meaning SDK and Sentry product work

Some of these links are surely conflated, the problem space needs to be mapped out better (I need to understand it better :) ) to understand what needs to be improved from the perspective of:

olksdr commented 1 year ago

@AbhiPrasad @smeubank Are you actively working on this issue? Can we remove assignees?

AbhiPrasad commented 1 year ago

We are not actively working on this, will remove.

guidobouman commented 10 months ago

@danielkhan Any intentions for Sentry to put this on the roadmap somewhere soon? Right now we're building a separate lambda as per the workaround. But we have issues with Sentry marking the events originating from the lambda, instead of from the client itself.

hubertdeng123 commented 10 months ago

Hm, not sure if there's a good product area that this should belong to, Settings - Security and Privacy seem the closest. However, the product owners there don't match up with who is responding in this thread. I'll follow up on this through a DM.

hubertdeng123 commented 10 months ago

Looks like @danielkhan is out of office. @AbhiPrasad or @smeubank, would either of you be able to answer the question?

AbhiPrasad commented 10 months ago

This is a little unowned right now, but we can figure that out.

Right now we're building a separate lambda as per the workaround. But we have issues with Sentry marking the events originating from the lambda, instead of from the client itself.

@guidobouman do you mind describing this workaround and what you are doing with the lambda? How is that related to the reporting API?

danielkhan commented 10 months ago

I am assigning this to me for now. Let's clarify the Lambda use case as @AbhiPrasad suggested. I will discuss this with @smeubank.

guidobouman commented 10 months ago

As the Reporting API is not yet supported with the ingestion endpoints, we've created our own minimal endpoint in which we receive the reports and manually send that into Sentry as a workaround. It's not a bug, just a feature request, so we don't have to maintain our own custom reporting endpoint.

guidobouman commented 10 months ago

Basically we've implemented the workaround from @AbhiPrasad's message:

Yup, crashes are probably the most useful thing we'd get here if we instrument this - it'll unlock a whole category of issues that previously weren't visible because we rely on JS to be running on the page.

For others who are following along, you can do this yourself while you wait for Sentry to build out a 1st class solution. You would:

  1. create a reporting API endpoint of yourself, easiest is probably a serverless function

  2. use a Sentry SDK with the sendEvent method that sends an event using our format (https://develop.sentry.dev/sdk/event-payloads/) to a Sentry project

So you would try mapping the report API format -> a Sentry event, and then sending that Sentry event to Sentry!

One minor problem we run into is the origin of those events.

guidobouman commented 10 months ago

One minor problem we run into is the origin of those events.

Actually, that origin from my previous comment is more of an issue. Because we're using a service (that has its own Sentry project) as a relay for the reporting API, we have problems linking the custom sendEvent to the correct project. Right now the crash reports get connected to the service Sentry project, instead of the frontend application Sentry project.

We've managed to impersonate the other project from our service, and can now send events into sentry on behalf of another project. Still, it's a manual proxy implementation, and would prefer to actually use the Sentry reporting endpoint when possible.

timfish commented 3 weeks ago

It's worth noting that Chrome can now include stack traces with unresponsive crashes via an origin trial.

https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/

timfish commented 3 weeks ago

I just had a look at the Relay code and the existing CSP endpoint "just" converts the CSP reports into envelopes: https://github.com/getsentry/relay/blob/fa1b2540b5003e3eb7ccac5d1150950f6661fbbe/relay-server/src/endpoints/security_report.rs

This could be added in a few steps:

  1. Add a /reporting-api/ endpoint
    • Only handles CSP reports initially so this would virtually be a copy of the existing CSP endpoint
    • The CSP reports are similar format but property names have changed
    • Drop/ignore all the other report types initially
  2. Add support for crash reports
    • This involves creating the correct envelope for each of oom and unresponsive
  3. Add support for parsing Chrome stack frames and including these in the envelopes

For the other types of reports, deprecation and intervention are far better handled via ReportingObserver in the browser SDK where you'll get a lot more context.