Audit.NET 在 Windows 身份验证下的审计问题解析

问题背景

在使用 Audit.NET 框架进行 Entity Framework Core 审计时，开发人员发现了一个特殊现象：当 Web API 启用 Windows 身份验证保护端点时，审计功能会失效，而匿名端点却能正常工作。这个现象在 .NET Core 8 环境中尤为明显。

核心问题分析

审计功能失效的根本原因在于 Audit.EntityFramework.Core 与依赖注入(DI)系统的集成方式。该库默认不会通过 DI 系统解析 AuditDataProvider，而是直接从 AuditDbContext 或全局配置中获取。当未正确配置数据提供程序时，系统会回退到默认的 FileDataProvider，这可能导致审计记录无法按预期保存。

解决方案详解

方案一：在 DbContext 中直接设置数据提供程序

public class CustomDbContext : AuditDbContext
{
    public CustomDbContext(DbContextOptions options, IServiceScopeFactory serviceScopeFactory) 
        : base(options)
    {
        this.AuditDataProvider = new CustomAuditDataProvider(serviceScopeFactory);
    }
}

这种方法直接在 DbContext 构造函数中实例化自定义的数据提供程序，确保每次创建 DbContext 时都能获得正确的审计配置。

方案二：设置全局默认数据提供程序

var app = builder.Build();
var serviceScopeFactory = app.Services.GetService<IServiceScopeFactory>();
Audit.Core.Configuration.Setup().Use(new CustomAuditDataProvider(serviceScopeFactory));

全局配置方式适合在整个应用程序中使用统一的审计策略，简化了配置管理。

优化自定义数据提供程序实现

更优雅的实现方式是利用 EF Core 提供的服务定位功能：

public class CustomAuditDataProvider : AuditDataProvider
{
    public override object InsertEvent(AuditEvent auditEvent)
    {
        var serviceScopeFactory = auditEvent
            .GetEntityFrameworkEvent()
            .GetDbContext()
            .GetService<IServiceScopeFactory>();
        
        // 使用 serviceScopeFactory 进行后续操作
    }
}

这种方法消除了对 IServiceScopeFactory 的显式依赖，使代码更加简洁。

异步方法实现要点

在实现自定义数据提供程序时，必须正确处理同步和异步方法：

1. 同步方法 InsertEvent 应返回 object 类型，不应包含异步操作
2. 异步方法 InsertEventAsync 应返回 Task<object> 类型，并接受 CancellationToken 参数

错误的实现方式（在同步方法中使用异步操作）可能导致死锁或性能问题。

最佳实践建议

1. 完整实现接口：同时实现同步和异步方法，确保所有操作场景都被覆盖
2. 依赖管理：尽量减少显式依赖，利用 EF Core 的服务定位功能
3. 错误处理：在数据提供程序中添加适当的错误处理逻辑
4. 性能考量：对于高并发场景，考虑使用更高效的审计存储方案
5. 测试验证：特别测试 Windows 身份验证和匿名访问的不同场景

通过以上方法，可以确保 Audit.NET 在各种身份验证模式下都能可靠地记录审计日志，满足企业级应用的安全审计需求。