docs(index): Auth 0.2.0 — LDAP sticky backup-DC failover published
This commit is contained in:
@@ -3,6 +3,20 @@
|
||||
Divergence of each project from [`spec/SPEC.md`](spec/SPEC.md), and the ordered backlog to
|
||||
reach the shared `ZB.MOM.WW.Auth` library. Status legend: ⛔ gap · 🟡 partial · ✅ matches.
|
||||
|
||||
> **`0.2.0` PUBLISHED 2026-08-10 — LDAP backup-DC sticky failover** (plan
|
||||
> `docs/plans/2026-08-10-ldap-backup-dc-failover.md`). New capability in `Auth.Ldap`: an additive
|
||||
> `LdapOptions.FallbackServers` list makes `LdapAuthService` walk primary + fallback endpoints,
|
||||
> failing over on **system-side** faults only (connect/TLS, service-account bind, search) while a
|
||||
> user-side answer (`Success`/`UserNotFound`/`AmbiguousUser`/`BadCredentials`/`GroupLookupFailed`)
|
||||
> is final and never retried elsewhere. Sticky endpoint preference (updates on any authoritative
|
||||
> answer), boot validation of entries, optional `ILogger` observability. Empty default = failover
|
||||
> off, single-endpoint behaviour byte-unchanged. No `Abstractions` contract change beyond the new
|
||||
> option; no `LdapAuthFailure` enum change. Motivation: ZB production directory is NAM AD with two
|
||||
> DCs. **4 pkgs on the feed at `0.2.0`, restore-verified.** **App adoption is a follow-up** — all
|
||||
> four apps still pin `0.1.5`; adopting means bumping the pin to `0.2.0` and authoring
|
||||
> `FallbackServers` (the backup DC + LDAPS trust for the ZB 1024-bit certs), deployment-time work
|
||||
> tracked in `ldap_setup.md`.
|
||||
|
||||
> **`0.1.5` PUBLISHED 2026-07-18 — security fix.** `Auth.ApiKeys` `0.1.4` and earlier ship a
|
||||
> high-severity transitive vuln: `Microsoft.Data.Sqlite 10.0.7` pulls
|
||||
> `SQLitePCLRaw.lib.e_sqlite3 2.1.11` (GHSA-2m69-gcr7-jv3q). `0.1.5` pins the patched `2.1.12`
|
||||
|
||||
Reference in New Issue
Block a user