Support Destructurama about serilog.exceptions HOT 8 CLOSED

Looked at the repo. It's a bad idea to be adding passwords to an exception, so I would simply not do that instead of using that library.

I think rather than deciding to support Destructurama, we should perhaps think about adding some extensibility that allows you to decide whether you want to log a property or not e.g.

bool CanLogProperty(Type type, string propertyName);

But not sure if this is useful, you are the first person to ask for a feature like this and like I say, adding secrets to exceptions is a bad idea.

from serilog.exceptions.

Fair point to argument.
In my case is not about secrets, but having Personal Identifiable Information (PII) data on custom exceptions.
For example, an exception that captures a request which posted PII data.

from serilog.exceptions.

Would it be possible to remove that data from the exceptions in the first place?

from serilog.exceptions.

Yes it is, but it'll be nicer to have the whole logging pipeline respecting the current applied enrichers.

from serilog.exceptions.

Thoughts @krajek?

from serilog.exceptions.

I agree @RehanSaeed.
The problem seems to be out of the domain of the library.
I do not know the details, so I may miss something, but it seems that exception should only contain some identifier (GUID for example) that would allow an authorized actor to reach for PII if necessary (debugging or audit purposes), secured by proper authorization.

@luizbon Alternatively, you could write your own destructurer for particular exception types. Maybe that's viable in your case.

from serilog.exceptions.

Fair enough, the downside of using identifiers is that it's required to have code to load the data on the exception handler that needs the data. But is understandable to have it.

My suggestion was related to the library respect the current enrichers configured on Serilog pipeline when destructing the exception. Probably I wasn't clear of this when opened the issue.
I'll close this issue as it's not relevant to the library.
Thanks

from serilog.exceptions.

Hi, would you be open to reconsidering this?
We use destructurama extensively in our system and recently added Serilog.Exceptions to our Serilog configuration.
To our surprise, unlike other libraries that plug into Serilog, this one doesn't respect destructurama attributes, so we are suddenly logging PII that we use as part of the exception flow, but that we were filtering out / masking using destructurama.

As an example, we have a phone number field in an exception, we mask it in the logs because it's PII. However, we are still interested in logging whether it was a null value, whether the length of the string was valid, or whether it's using a country prefix that we don't support.
Until now we only needed to add [LogMasked] to the property, and we knew that any serialization to logs would be masked properly.

from serilog.exceptions.