Current situation:
The ScopeProvider has several "slots" of information, such as "environment", "tags", "release", "tags" and "user".
There's an individual chain of *Provider classes for each slot.
Every such class can add data.
Each provider is unaware of the data other providers contributed, as well as the data already present in the Sentry\Event during runtime. So those calls are more or less static, although they can depend on user input such as e.g. the currently logged in frontend user.
Obstacle:
-
There is no way of overruling existing data by reading it from the Event object, manipulating it, and adding it back to the event.
Real world example: Replace the POST payload with an encrypted version of it.
- Try and recreate the POST body exactly like Sentry did (by copying Sentry code because this part is
private).
- Overwrite every POST body attribute with
null, hoping to eliminate existing data.
- Encrypt and export in a new POST body attribute.
This isn't particularly confidence inspiring because every Sentry update might change the way this data is named slightly without me knowing I'm pushing unencrypted data to Sentry again.
-
Making changes in two slots at once isn't possible.
The mentioned feature of encrypting POST body data should add a link to the neos backend, targeting a backend module where administrators can decrypt and review this data.
This link should go into the "Extras" section, not into the POST body.
What should we do?
- Introduce the concept of
EventProcessors.
EventProcessors have a separate configuration section in the yaml file.- The
EventProcessor should take an Event and update it or replace it entirely.
- Make the
NetlogixIntegraton walk through the chain of EventProcessors exactly where currently the ScopeProcessor is asked for collection slot data.
- Move all
ScopeProvider::collect* methods into individual *EventProcessor classes.
This should, from the perspective of yaml configuration and interfaces in the "Scope" folder, with no breaking change while adding a new layer of event manipulation capability.
Current situation:
The
ScopeProviderhas several "slots" of information, such as "environment", "tags", "release", "tags" and "user".There's an individual chain of
*Providerclasses for each slot.Every such class can add data.
Each provider is unaware of the data other providers contributed, as well as the data already present in the
Sentry\Eventduring runtime. So those calls are more or less static, although they can depend on user input such as e.g. the currently logged in frontend user.Obstacle:
There is no way of overruling existing data by reading it from the Event object, manipulating it, and adding it back to the event.
Real world example: Replace the POST payload with an encrypted version of it.
private).null, hoping to eliminate existing data.This isn't particularly confidence inspiring because every Sentry update might change the way this data is named slightly without me knowing I'm pushing unencrypted data to Sentry again.
Making changes in two slots at once isn't possible.
The mentioned feature of encrypting POST body data should add a link to the neos backend, targeting a backend module where administrators can decrypt and review this data.
This link should go into the "Extras" section, not into the POST body.
What should we do?
EventProcessors.EventProcessorshave a separate configuration section in the yaml file.EventProcessorshould take anEventand update it or replace it entirely.NetlogixIntegratonwalk through the chain ofEventProcessorsexactly where currently theScopeProcessoris asked for collection slot data.ScopeProvider::collect*methods into individual*EventProcessorclasses.This should, from the perspective of yaml configuration and interfaces in the "Scope" folder, with no breaking change while adding a new layer of event manipulation capability.