Innovabit.DotNet.Interceptors.Audit.Abstractions 2.0.117

Innovabit.DotNet.Interceptors.Audit.Abstractions

Business audit trails for Innovabit.DotNet.Interceptors via an [Audited] attribute. This is the provider-agnostic base: it ships the interceptor, the attribute, the AuditEntry shape and the IAuditSink abstraction. Pick a sink — or write one — to decide where entries are kept:

• Innovabit.DotNet.Interceptors.Audit.EntityFrameworkCore — one row per entry, in your database.

Audit is not logging

Put [Audited] on the handful of operations someone might one day have to answer for, not on everything.

Usage

services
    .AddInterceptors()
    .AddEntityFrameworkCoreAudit<BillingDbContext>()     // or .AddAuditSink<MyOwnSink>()
    .UseAuditSubjectAccessor<HttpAuditSubjectAccessor>();

services.AddScopedWithInterception<IRefundService, RefundService>();

public class RefundService : IRefundService
{
    [Audited(Action = "order.refunded", Category = "finance")]
    public Task<Refund> RefundAsync(string orderId, decimal amount, [AuditIgnore] string internalNote)
    { ... }
}

[Audited]

Parameters marked [AuditIgnore] are recorded as ***, and CancellationToken parameters are left out entirely. [AuditIgnore] keeps a parameter out of the audit trail specifically; the cross-cutting [Sensitive] and [Mask] from the core package keep it out of every record the suite writes — logs, spans and exception notifications included — and are applied here as well.

Sensitive members inside an argument

The default IAuditSerializer honours [Sensitive] and [Mask] on the properties and fields of whatever it writes out, so the rules keep working once a value stops being an argument and becomes an object inside one:

public class Customer
{
    public string Name { get; set; }
    [Sensitive] public string Email { get; set; }
    [Mask(ShowLast = 4)] public string CardNumber { get; set; }
}

[Audited(Action = "order.placed")]
public Task PlaceAsync(Order order) { ... }

The stored row keeps {"Name":"Ada Lovelace","Email":"***","CardNumber":"************1111"}, through nested objects and collections alike, while the method itself still receives the real object. A serializer of your own opts in with one line — see RedactionJsonModifier in the core package.

When serialization fails outright, the entry records <unserializable: Type.Name> rather than ToString(): a record's generated ToString prints every property, marked ones included, which would turn a serialization failure into exactly the leak the attributes exist to prevent. The redaction is deliberate: an entry that silently dropped an argument would be indistinguishable from one where it was never passed, which is exactly the ambiguity an audit exists to remove.

What an entry carries

AuditEntry holds the action and category, the type and method, the arguments, the outcome (Succeeded, plus ExceptionType/ExceptionMessage on failure), OccurredAt and Duration, the Subject, and a CorrelationId taken from the ambient Activity — so an entry lines up with the trace of the request that produced it.

Who did it

Only your application knows where the current user lives, so IAuditSubjectAccessor is the one thing you have to supply. The default reads Thread.CurrentPrincipal, which ASP.NET Core does not set — a web application registers its own:

public sealed class HttpAuditSubjectAccessor(IHttpContextAccessor accessor) : IAuditSubjectAccessor
{
    public string? GetSubject() => accessor.HttpContext?.User.Identity?.Name;
}

services.AddInterceptors().UseAuditSubjectAccessor<HttpAuditSubjectAccessor>();

An accessor that throws leaves Subject empty rather than failing the operation.

Ordering

The interceptor runs at InterceptorOrders.Audit (50) — just inside logging, outside validation. That is what makes rejected attempts show up in the trail: a call turned away by validation, authorization or a business rule is still recorded, because "who tried to do what" is half of what an audit is for.

A failing sink never fails the call

Whatever a sink throws is swallowed. An audit trail that takes the business operation down with it when the audit store hiccups is worse than one with a gap — so a sink that cannot afford to lose entries should do its own durable buffering rather than rely on the exception surfacing.

Writing a sink

public sealed class FileAuditSink(IAuditSerializer serializer) : IAuditSink
{
    public ValueTask WriteAsync(AuditEntry entry, CancellationToken cancellationToken = default) { ... }
    public void Write(AuditEntry entry) { ... }
}

services.AddInterceptors().AddAuditSink<FileAuditSink>();

Register as many as you like — every sink gets every entry.

License

MIT