Options, JWT bearer validation, the /meta and .well-known endpoints, and a dev compose
stack with Keycloak. Verified end to end: compose up, migrate, run, both discovery
endpoints return correct payloads, and readiness reports the schema current.
Configuration:
- Strongly-typed options for Server, Oidc, Relay and Sync, all ValidateOnStart. A
self-hosted server that boots half-configured and fails later per-request is far harder
to diagnose than one that refuses to start and names the bad setting.
- Cross-field validation the annotations cannot express: relay needs a WebSocketUrl when
enabled, idle timeout must be under max session duration, item payload cap under batch cap.
- Startup warnings for combinations that are individually valid but dangerous together:
RequireHttpsMetadata false outside Development, and AllowEmailLinking (which turns any
token bearing a victim's email into account takeover, hence default false).
Auth:
- JwtBearer with ClockSkew cut to 30s from the 5-minute default; five minutes of slack on a
credential granting vault ciphertext access is more than any clock needs.
- IncludeErrorDetails off, and a FallbackPolicy so an endpoint without an explicit policy
still requires a caller rather than silently being public.
Discovery, per ADR 0002:
- /api/v1/meta reports versions, features and push caps.
- /.well-known/dodossh-configuration is the onboarding story: the user types one server URL
and the client discovers OIDC authority, client id, scopes and relay endpoint.
Two environment problems found by actually running the stack:
- PostgreSQL 18 changed its data mount point. Mounting /var/lib/postgresql/data — correct
through 17 — makes the image refuse to start; 18+ wants a single mount at
/var/lib/postgresql with the cluster in a subdirectory.
- Keycloak moved to host port 18080. An unrelated Apache Tomcat on this machine holds
127.0.0.1:8080, and a loopback-specific bind beats Docker's 0.0.0.0 publish for
"localhost". It presents as Keycloak 404ing every realm while its own log says the import
succeeded, which is a genuinely misleading failure.
Also: CA1848 is enforced, not advisory — warnings are errors, so the .editorconfig comment
claiming otherwise was wrong. Startup and health logging now uses [LoggerMessage]. And a
clean rebuild is back to zero warnings; the incremental build had been hiding 40 in test
projects (banned Guid.NewGuid, an obsolete Testcontainers constructor, and two analyzer
families that are genuinely noise under a test host).
Verified: 0 warnings on a clean rebuild, 122 tests pass, format clean.
Schema for identity, vaults, grants, hosts and the sync change log, verified against a
real PostgreSQL 18 container rather than an in-memory provider: partial unique indexes,
CHECK constraints, citext and identity-always columns are all provider behaviour that an
in-memory fake would not exercise.
Invariants pushed into the database, so they hold even when application code has a bug:
- ck_host_relay_target is a security boundary, not tidiness. A host may carry a plaintext
hostname and port ONLY when relay is deliberately enabled. Both directions are tested;
the important one is that relay-disabled hosts cannot carry an address, since otherwise
a bug would silently give the server infrastructure visibility it was never granted.
- ck_vault_owner: exactly one of owner_user_id or team_id, or permission resolution would
have no defined answer.
- ck_vault_key_grant_recipient: member grants name a user; recovery and escrow grants are
wrapped to a key and must not.
- ck_user_key_wrap_kdf: a password-derived wrap without its parameters is permanently
unopenable, so a partial write is rejected outright.
Present from the first migration on purpose:
- GrantKind (Member/Recovery/Escrow). Recovery cannot be bolted on later — every vault
created before it existed would be unrecoverable by design.
- team and team_membership, though team features are M3. Adding them later would mean
introducing a foreign key on a live vault table.
- Host.ContentKeyId, reserved for per-item content keys wrapped to individual users.
- user_key as its own table, so key rotation does not require altering the user row.
Two things verified rather than assumed:
- Npgsql's UseXminAsConcurrencyToken helper no longer exists in EF 10, so xmin is mapped
directly in XminConcurrency. The generated migration *looks* like it creates an xmin
column; it does not. Confirmed by inspecting pg_attribute (attnum -2, a system column)
and by grepping the emitted DDL. A test pins both, because had it created a real column
PostgreSQL would have rejected the name.
- EF Core is now pinned centrally. The Npgsql provider asks for 10.0.4 while
EntityFrameworkCore.Design pulls 10.0.10, and because Design is PrivateAssets=all that
higher version does not flow to referencing projects — producing a CS1705 in any test
project referencing Infrastructure.
Also commits artifacts/schema/v0.1.sql, the idempotent script, as the baseline for future
upgrade tests.
Verified: 0 warnings, 122 tests pass (27 new against Postgres), format clean.
jaap-jan