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

Add migration guide for SharpRaven #243

Open
mrmonday opened this issue Jul 18, 2019 · 4 comments

Comments

@mrmonday
Copy link

commented Jul 18, 2019

We currently use the legacy SharpRaven nuget package, and are looking to migrate.

Some things that are not immediately obvious from reading the documentation (my apologies if I've missed this information):

  • What is the replacement for SentryUserFactory?
  • Is ASP.NET (Framework) integration supported?
  • What is the replacement for LogScrubber?
  • What is the recommended way to move away from RavenClient? Currently we create a global instance at application startup, and use this throughout. With SentrySdk.Init(), all the examples use a using statement - should we initialise whenever we log an exception, or continue using a global instance and disposing on application shutdown?
@bruno-garcia

This comment has been minimized.

Copy link
Member

commented Jul 18, 2019

Fair point. It's overdue actually.
I'll address your points here but I'll get something on docs.sentry.io after that:

What is the replacement for SentryUserFactory?

For ASP.NET Core, you'd just register IUserFactory in the container. That'll replace the DefaultUserFactory Sentry's SDK registers. There's no UserFactory for ASP.NET classic at the moment. If you'd need that, we'll need to add it here.

Is ASP.NET (Framework) integration supported?

Yes. When an exception goes out we look for the static HttpContext.Current and read the request data into the event. The code for populating the event is this. We have an internal abstraction over HttpRequest which includes an adapter to System.Web's.

What is the replacement for LogScrubber?

It's creating an IEventProcessor. With that you can modify the event, returns a new instance, or drop the event altogether (return null).
In ASP.NET Core you just register as many ISentryEventProcessor as you want`. In other environments you can add an instance to the options:

SentrySdk.Init(o =>
{
   o.AddEventProcessor(new MyEventProcessor());
});

You can also do that with the BeforeSend callback (defined in the options) which is a simply Func<SentryEvent, SentryEvent>.

What is the recommended way to move away from RavenClient? Currently we create a global instance at application startup, and use this throughout. With SentrySdk.Init(), all the examples use a using statement - should we initialise whenever we log an exception, or continue using a global instance and disposing on application shutdown?

The Init() method returns a IDisposable which you can hold on to for the whole lifetime of the app. Calling Dispose on it will ensure we drain the queue before your apps shuts down. You can also call SentrySdk.Close().
So after calling SentrySdk.Init() your calls to SentrySdk.Capture*, Sentry.Sdk.ConfigureScope, etc will actually have side effect. If the SDK is not enabled, all these calls no-op.
If you want to unit test your code you'll likely rely on ISentryClient and IHub. More on that on our docs.

@mrmonday

This comment has been minimized.

Copy link
Author

commented Jul 18, 2019

Thanks for your quick, and thorough, response.

There's no UserFactory for ASP.NET classic at the moment. If you'd need that, we'll need to add it here.

Shall I open another issue for this?

It's creating an IEventProcessor.

So we should write our own logic for scrubbing credit card/phone data? This was included directly in SharpRaven.

Calling Dispose on it will ensure we drain the queue before your apps shuts down.

Is there a way to ensure the queue is drained earlier/ensure events are sent synchronously? That is, without disposing the object returned from Init().

@bruno-garcia

This comment has been minimized.

Copy link
Member

commented Jul 18, 2019

Shall I open another issue for this?

Please feel free. Hasn't been requested yet.

So we should write our own logic for scrubbing credit card/phone data? This was included directly in SharpRaven.

We have that scrubbing on the server. Also we're building a relay which would allow you control scrubbing on-prem if your prefer, at a centralized place, with much more sophisticated approach. You'll be able to control that from sentry.io too if you prefer. I'd suggest copying the code from SharpRaven for now if that's really what are looking for. Or perhaps start a sentry-dotnet-contrib or publish your own package with additions but at this point we don't plan to add client side scrubbing to the SDKs.

Is there a way to ensure the queue is drained earlier/ensure events are sent synchronously? That is, without disposing the object returned from Init().

Yes. await SentrySdk.FlushAsync(timeout) will give you that.

@mrmonday

This comment has been minimized.

Copy link
Author

commented Jul 18, 2019

Shall I open another issue for this?

Please feel free. Hasn't been requested yet.

Done - #244

We have that scrubbing on the server.

This won't cut it for cardholder data - for PCI-DSS compliance we cannot send Sentry cardholder data. There shouldn't be any such data in exceptions anyway, but it needs to be filtered on our side just in case.

Again, thanks for your response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.