elsa-core/src/modules/Elsa.Secrets.Persistence.EFCore/SecretConfiguration.cs

36 lines
2.3 KiB
C#
Raw Normal View History

2026-05-31 19:57:09 +00:00
using Elsa.Secrets.Models;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
namespace Elsa.Secrets.Persistence.EFCore;
internal class SecretConfiguration : IEntityTypeConfiguration<Secret>
{
public void Configure(EntityTypeBuilder<Secret> builder)
{
builder.HasKey(x => x.Id);
builder.Ignore(x => x.Tags);
builder.Ignore(x => x.Versions);
builder.Ignore(x => x.LatestActiveVersion);
2026-06-01 19:45:53 +00:00
builder.Property<string>(SecretShadowPropertyNames.SerializedTags).HasColumnName("Tags").IsRequired();
builder.Property<string>(SecretShadowPropertyNames.SerializedVersions).HasColumnName("Versions").IsRequired();
2026-05-31 19:57:09 +00:00
builder.Property(x => x.Name).HasMaxLength(200).IsRequired();
2026-06-01 19:45:53 +00:00
builder.Property<string>(SecretShadowPropertyNames.NormalizedName).HasMaxLength(200).IsRequired();
2026-05-31 19:57:09 +00:00
builder.Property(x => x.DisplayName).HasMaxLength(200).IsRequired();
builder.Property(x => x.TypeName).HasMaxLength(100).IsRequired();
builder.Property(x => x.StoreName).HasMaxLength(100).IsRequired();
builder.Property(x => x.Scope).HasMaxLength(200);
builder.Property(x => x.Status).HasConversion<string>().HasMaxLength(32).IsRequired();
test(secrets): add File/InMemory/EF tenancy conformance matrix (#8143) * test(secrets): add File/InMemory/EF tenancy conformance matrix Shared ISecretRepository scenarios for per-tenant uniqueness, Get/List isolation, deleted replace, and default-tenant duplicate rejection. Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com> * fix(secrets): enforce default-tenant uniqueness via empty TenantId Stamp leftover null TenantId values to "" before rebuilding the per-tenant unique index, matching Labels. Fail loud on leftover duplicate names instead of silently deduping. New EF writes in the default tenant persist "". Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com> * fix(secrets): make default-tenant uniqueness migrate on SQLite Use the schema-less Secrets table name, let CreateIndex fail loudly when leftover duplicates remain, and isolate the tenant-aware EF model cache from the non-tenant fixture. Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com> * test(secrets): avoid Path.Combine drop in uniqueness migration tests Reject rooted provider project paths and use Path.Join when locating Elsa.sln so CodeQL does not warn about discarded path segments. Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com> * fix(secrets): enforce Oracle default-tenant uniqueness via NVL index Oracle stores '' as NULL, so a TenantId IS NOT NULL filtered unique index left default-tenant secret names uncovered. Use NVL(TenantId, CHR(1)) so those rows share one index key. Stamp stays for preflight grouping; leftover duplicates still fail loud with no silent dedupe. Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
2026-09-14 05:03:16 +00:00
// Uniqueness is per tenant, matching Labels (and User, Role, Application).
// A global unique index would make the name a shared resource across tenants.
// SQL Server still emits a filtered unique index (TenantId IS NOT NULL); leftover
// nulls are stamped to "" first. Oracle stores '' as NULL, so that provider uses
// a function-based unique index on NVL(TenantId, CHR(1)) instead of a filter.
feat(secrets)!: scope secrets to tenants (#7991) * feat(secrets)!: scope secrets to tenants Secret was the one user-facing entity with no notion of tenancy. It did not derive from Entity, so it carried no TenantId and no query filter applied to it: in a multi-tenant deployment every tenant could see and resolve every other tenant's secrets. Permissions did not help, because secrets:view is evaluated against the caller rather than against which tenant owns the secret, so any caller holding it reached the whole set. Secret now derives from Entity and is filtered like everything else. The infrastructure was already in place -- SecretsElsaDbContext derives from ElsaDbContextBase and the feature from PersistenceFeatureBase, which registers SetTenantIdFilter -- and the handler was skipping secrets for one reason: it only applies to Entity. No backfill, deliberately. The column is added nullable and existing rows keep a null tenant, because SetTenantIdFilter already treats null as the default tenant through a clause written for exactly this case. Single-tenant deployments see no change at all, since the filter is only installed when multitenancy is enabled. Multi-tenant deployments find pre-existing secrets invisible until assigned, which is a visible failure rather than continued cross-tenant exposure. Two things this needed that were not obvious: Secret self-initialized its Id and nothing else ever assigned one -- there is no identity generator on the create path -- while Entity.Id is null!. Simply deriving would have produced a null id on every insert, which any test that builds a Secret by hand would have missed. A constructor preserves it. The unique index moves from NormalizedName to (TenantId, NormalizedName), matching User, Role and Application in the same release. Leaving it global would have made secret names a shared resource: the second tenant to want "smtp-password" could not create one. Elsa.Secrets.Persistence.VNext cannot support this. It keys documents by name alone and Elsa.Persistence.VNext has no tenant concept to filter on, so it now throws outside the default tenant rather than serving one tenant's secret to another. Making it tenant-aware means changing the document id scheme, which relocates existing documents and is a storage change to make deliberately. Refs #7972 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(secrets): let the VNext repository resolve without multitenancy The tenancy guard took ITenantAccessor as a required dependency. That interface is registered by the tenants module, so a host that never added multitenancy has none, and resolving ISecretRepository threw for exactly the deployments the guard is meant to leave alone. The accessor is now optional, and its absence means no tenancy, which is the default tenant. Found by review, and it is worth naming why the tests missed it: every case in VNextSecretRepositoryTests constructs the repository directly with a stub accessor, so none of them ever went through the container where the failure lived. The new case resolves through a service collection that adds only the document store and the module's own registration, which is what a single-tenant host looks like. Reverting the fix makes it fail with the same missing-service exception review reported. Refs #7972 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 23:56:55 +00:00
builder.HasIndex("TenantId", SecretShadowPropertyNames.NormalizedName).HasDatabaseName($"IX_{nameof(Secret)}_TenantId_{SecretShadowPropertyNames.NormalizedName}").IsUnique();
2026-05-31 19:57:09 +00:00
builder.HasIndex(x => x.TypeName).HasDatabaseName($"IX_{nameof(Secret)}_{nameof(Secret.TypeName)}");
builder.HasIndex(x => x.StoreName).HasDatabaseName($"IX_{nameof(Secret)}_{nameof(Secret.StoreName)}");
builder.HasIndex(x => x.Scope).HasDatabaseName($"IX_{nameof(Secret)}_{nameof(Secret.Scope)}");
builder.HasIndex(x => x.Status).HasDatabaseName($"IX_{nameof(Secret)}_{nameof(Secret.Status)}");
}
}