Stratara.Validation
4.6.0
Prefix Reserved
See the version list below for details.
dotnet add package Stratara.Validation --version 4.6.0
NuGet\Install-Package Stratara.Validation -Version 4.6.0
<PackageReference Include="Stratara.Validation" Version="4.6.0" />
<PackageVersion Include="Stratara.Validation" Version="4.6.0" />
<PackageReference Include="Stratara.Validation" />
paket add Stratara.Validation --version 4.6.0
#r "nuget: Stratara.Validation, 4.6.0"
#:package Stratara.Validation@4.6.0
#addin nuget:?package=Stratara.Validation&version=4.6.0
#tool nuget:?package=Stratara.Validation&version=4.6.0
Stratara.Validation
Derived. The behaviour described here is specified under
openspec/specs/. Those specifications are the source; this page explains and illustrates them.
License: MIT.
Vendor-neutral request validation for Stratara's CQRS pipeline. A mediator pipeline behavior
runs your IValidator<T> implementations before the handler and throws an aggregated
StrataraValidationException when validation fails — no third-party validation dependency in
the default path.
Quick start
// 1. Register the behavior (outermost) + discover validators.
builder.Services
.AddStrataraValidation()
.AddValidatorsFromAssemblyContaining<IAppMarker>();
// 2. Write a validator (the contracts live in Stratara.Abstractions.Validation).
public sealed class CreateOrderValidator : IValidator<CreateOrder>
{
public ValueTask<ValidationResult> ValidateAsync(CreateOrder cmd, CancellationToken ct = default)
=> ValueTask.FromResult(string.IsNullOrWhiteSpace(cmd.CustomerId)
? new ValidationResult([new ValidationFailure(nameof(cmd.CustomerId), "Customer is required.")])
: ValidationResult.Success);
}
// 3. Catch the failure in your global handler and map it to your error model.
catch (StrataraValidationException ex)
{
// ex.Failures -> RFC-7807 ProblemDetails 400, your error codes, etc.
}
How it works
AddStrataraValidation()registersIPipelineBehaviorfor both request shapes (IRequestandIRequest<TResult>). Register it before other behaviors so validation runs outermost — before authorization, auditing, and the handler.- All validators for a request run; their failures are aggregated.
- Severity policy: only
ValidationSeverity.Errorblocks (throwsStrataraValidationException).WarningandInfofailures pass through and are logged.
Contracts
The validation contracts (IValidator<T>, ValidationResult, ValidationFailure,
ValidationSeverity, StrataraValidationException) live in Stratara.Abstractions
(namespace Stratara.Abstractions.Validation) so consumers can implement validators and catch
the exception without referencing this behavior package.
The contract shape is FluentValidation-compatible; an optional
Stratara.Validation.FluentValidation adapter can be shipped to plug FluentValidation
validators into the same pipeline.
Dependencies
Stratara.AbstractionsStratara.MediatorStratara.DiagnosticsMicrosoft.Extensions.DependencyInjection.AbstractionsMicrosoft.Extensions.Logging.Abstractions
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- JetBrains.Annotations (>= 2026.2.0)
- Microsoft.Extensions.DependencyInjection.Abstractions (>= 10.0.13)
- Microsoft.Extensions.Logging.Abstractions (>= 10.0.13)
- Stratara.Abstractions (>= 4.6.0)
- Stratara.Diagnostics (>= 4.6.0)
- Stratara.Mediator (>= 4.6.0)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 4.8.0 | 144 | 11/6/2026 |
| 4.7.1 | 83 | 11/5/2026 |
| 4.7.0 | 536 | 10/30/2026 |
| 4.6.1 | 95 | 10/29/2026 |
| 4.6.0 | 192 | 10/28/2026 |
| 4.5.0 | 272 | 10/28/2026 |
| 4.4.10 | 203 | 10/26/2026 |
| 4.4.9 | 111 | 10/26/2026 |
| 4.4.8 | 252 | 10/24/2026 |
| 4.4.7 | 115 | 10/23/2026 |
| 4.4.6 | 221 | 10/22/2026 |
| 4.4.5 | 648 | 10/14/2026 |
| 4.4.4 | 395 | 10/10/2026 |
| 4.4.3 | 124 | 10/10/2026 |
| 4.4.2 | 470 | 10/2/2026 |
| 4.4.1 | 429 | 9/29/2026 |
| 4.4.0 | 152 | 9/27/2026 |
| 4.3.1 | 136 | 9/25/2026 |
| 4.3.0 | 400 | 9/23/2026 |
| 4.2.0 | 160 | 9/18/2026 |
An erasure shreds every key that names the subject, and nothing stopped the next encryption for that subject
from creating a new one: a key store asked for a scope it does not hold creates a first version. A job, a request
in flight or a second process that encrypted for an erased subject afterwards got a fresh key, and what it wrote
stayed readable for good. The key store now records an erased subject and refuses to create a key for it again.
### Added
- **`IKeyStore.MarkSubjectErasedAsync(KeySubject)`** records that a tenant or user has been erased. It has a
default implementation that throws `NotSupportedException`, so an existing key store still compiles.
- **`KeySubject`** names the tenant or user, and `KeySubject.Covers(KeyScope)` states which keys belong to its
erasure: for a tenant, a key of any level that names it; for a user, a user-level key that names it.
- **`KeyScopeErasedException`** (an `InvalidOperationException`) is what a key store throws for such a scope. It
carries the refused `Scope`.
### Changed
- **An encryption for an erased subject fails.** After a subject's erasure, `GetOrCreateCurrentKeyAsync` and
`RotateAsync` throw `KeyScopeErasedException` for every scope the subject covers, whether or not it ever held a
key, and create nothing. The blob encryptor, the encrypting settings store and the field-encrypting serializer
pass it through. Code that erased a subject and then wrote encrypted data for it again now sees the exception;
the mark is permanent and cannot be lifted. Revoking every version of a scope is not an erasure and marks nothing.
- **`ISubjectEraser` marks the subject before it sweeps any plane**, so an encryption racing the erasure
either creates its key first, and that key is shredded with the rest, or is refused. A key store that cannot mark
a subject leaves the erasure as before and logs `SubjectNotMarkable` (112009).
- **The file-backed key store writes format version 2**, which holds the marks, and refuses to open a file in a
newer format than it knows. `InMemoryKeyStore` refuses an erased subject as the file store does; `DummyKeyStore`
refuses to mark one, as it refuses every erasure operation.
**Upgrading:**
- **Upgrade every process that shares a key store file in one step.** A process on an earlier release reads a
version-2 file, ignores the marks, creates keys for an erased subject and drops the marks the next time it writes
the file. A version-1 file needs no migration. Rolling back is possible but loses the marks on the first write.
- **Map `KeyScopeErasedException` to your answer for data that is gone**, if a request can reach an encryption for
a subject after its erasure.
- **A key store of your own implements `MarkSubjectErasedAsync`**, refusing in `GetOrCreateCurrentKeyAsync` and
`RotateAsync` every scope a marked subject `Covers`. Without it the erasure warns and the gap stays open.