Docs
Tenantry CoreAPI reference

EfCoreIsolationOptions class

Namespace: Tenantry.EfCore · Package: Tenantry.EfCore · API reference

Options for configuring EF Core tenant isolation registration. Passed to builder.AddEfCoreIsolation(options => ...).

These protections are always on, independent of these options: reads fail closed (query filters match nothing when no tenant is resolved); Modified/Deleted entities must belong to the current tenant, checked before saving and again by the stored tenant in each UPDATE/DELETE; and ExecuteUpdate cannot set TenantId. These options govern writes without a tenant and inserts that name another tenant. Raw SQL and IgnoreQueryFilters() are outside Tenantry's isolation.

public sealed class EfCoreIsolationOptions

Properties

DetectSpoofedWrites

When true, an Added entity that carries an explicitly-set TenantId belonging to a tenant other than the current one throws TenantIsolationViolationException before any data is written (spoofing detection). When false (the default), such a value is silently overwritten with the current tenant by the stamping interceptor.

public bool DetectSpoofedWrites { get; set; }

Value: bool

OnMissingTenant

What happens when SaveChanges writes ITenantScoped<TKey> entities without a resolved tenant. Saves that write no tenant-scoped entity are never affected.

MissingTenantBehavior.Warn and MissingTenantBehavior.Allow are for maintenance code that deliberately writes across tenants: updates and deletes are then not tenant-checked, and a new entity must set its TenantId explicitly, because an unowned row is always rejected. Reads always fail closed, whatever this setting.

public MissingTenantBehavior OnMissingTenant { get; set; }

Value: MissingTenantBehavior

Exceptions:

  • ArgumentOutOfRangeException: The value is MissingTenantBehavior.Skip (which only applies to background-job propagation) or not a defined value.

On this page