ASP.NET Core多租户应用全局查询过滤器HttpContext缺失问题咨询

我正在开发一个多租户ASP.NET Core应用，需基于HttpContext中存储的当前用户凭据实现全局查询过滤器。我使用Entity Framework Core的全局查询过滤器功能，基于UserId对Account、Category、Transaction和Budget等实体进行过滤。

以下是简化代码片段：

private void SetGlobalQueryFilters(ModelBuilder modelBuilder)
{
    string userId = _httpContextAccessor?.HttpContext?.User?
        .FindFirst(ClaimTypes.NameIdentifier)?.Value ?? string.Empty;

    if (!Guid.TryParse(userId, out Guid result))
    {
        result = Guid.Empty;
        _logger.LogWarning("Unable to parse user id from HTTP context");
    }

    modelBuilder.Entity<Account>().HasQueryFilter(x => x.UserId == result);
    modelBuilder.Entity<Category>().HasQueryFilter(x => x.UserId == result);
    modelBuilder.Entity<Transaction>().HasQueryFilter(x => x.UserId == result);
    modelBuilder.Entity<Budget>().HasQueryFilter(x => x.UserId == result);
}

HttpContext可用时代码运行正常，但迁移期间HttpContext不存在会引发异常。为避免数据泄露，我需处理该场景，现咨询：

1. 迁移等场景下HttpContext不可用的最佳处理方案是什么？
2. 使用00000000-0000-0000-0000-000000000000作为UserId不可用时的过滤默认值，是否简洁且可接受？

1. 迁移等无HttpContext场景的最佳处理方案 #

• 分离迁移专用DbContext：创建一个不带全局查询过滤器的DbContext，仅用于执行EF迁移操作；应用运行时使用带过滤逻辑的DbContext。这种方式彻底隔离迁移与业务逻辑，从根源避免数据泄露风险，是最安全的方案。
• 通过环境变量标记迁移状态：执行迁移命令时设置环境变量（如EF_MIGRATION_RUNNING=true），在DbContext中读取该变量，若为true则临时跳过全局过滤逻辑（或设置x => true允许全量访问），生产环境严格启用过滤。
• 检查HttpContext有效性：设置过滤器前先判断_httpContextAccessor.HttpContext是否存在。若在生产环境无有效HttpContext，直接抛出异常或返回空结果；开发环境可临时禁用过滤，方便调试。

2. 使用Guid.Empty作为默认值的合理性 #

• 安全性：如果业务数据中绝对不存在UserId为Guid.Empty的记录，该方案是安全的，过滤器会返回空结果，避免数据泄露。但如果存在此类数据（如系统初始化的公用数据），则会导致数据错误过滤或泄露，此时不可用。
• 简洁性：确实简洁，代码逻辑清晰易懂，无需额外配置。
• 潜在风险：后续业务若意外生成Guid.Empty的UserId数据，会引发访问异常；无HttpContext场景下返回空结果，可能增加问题排查难度，不如明确抛出异常或记录更详细的日志。

总结：若能确保业务中永远不会出现Guid.Empty的UserId，该方案可接受；但从长期维护和安全性角度，更推荐结合场景判断（如迁移时跳过过滤）的方案，而非单纯依赖默认值。

内容的提问来源于stack exchange，提问作者Rade Tomovic