Mark some properties as sensitive

Is your feature request related to a problem? Please describe.

Actually when we use FluentValidation and there are errors the value is stored in clear text.

If we log this errors we could have some sensitive data like passwords, credit card number, …

For exemple here is a logged error in Seq :

{
  "AttemptedValue": "toto",
  "CustomState": null,
  "ErrorCode": "EqualValidator",
  "ErrorMessage": "La confirmation n''est pas identique au mot de passe.",
  "FormattedMessagePlaceholderValues": {
    "ComparisonProperty": "Password",
    "ComparisonValue": "titi",
    "PropertyName": "Confirm Password",
    "PropertyValue": "toto"
  },
  "PropertyName": "ConfirmPassword",
  "Severity": "Error"
}

Describe the solution you’d like

We can hide properties from logging in Serilog using Destructurama (https://github.com/destructurama/attributed)

public class CustomizedMaskedLogs
{
    /// <summary>
    /// 123456789 results in "***"
    /// </summary>
    [LogMasked]
    public string Password { get; set; }

    /// <summary>
    /// 123456789 results in "***"
    /// </summary>
    [LogMasked]
    public string ConfirmPassword { get; set; }
}

Then the log would look like this :

{
  "AttemptedValue": "***",
  "CustomState": null,
  "ErrorCode": "EqualValidator",
  "ErrorMessage": "La confirmation n''est pas identique au mot de passe.",
  "FormattedMessagePlaceholderValues": {
    "ComparisonProperty": "Password",
    "ComparisonValue": "***",
    "PropertyName": "Confirm Password",
    "PropertyValue": "***"
  },
  "PropertyName": "ConfirmPassword",
  "Severity": "Error"
}

Even if it would be very convenient for me, I’m not sure this would be the best way to mark the data as sensitive for FluentValidation.

Describe alternatives you’ve considered

One option could be to mark them as sensitive

RuleFor(m => m.Password).NotEmpty().Sensitive();

Additional Context

No response

[JeremySkinner]

I don’t think an interface adds any value here.

An interface with a single method has the same end result as a settable func - both provide a contract, the difference being an interface provides a contract for a class and a delegate provides a contract for a method; one is an object-oriented approach, the other is a more functional approach. The end result is the same - you’re replacing the method implementation.

[JeremySkinner]

I’ve pushed out 11.6.0 with this change