A gap, not a refinement. T10.2's task text said the login change "must add
visibility: a startup log line stating whether LDAP is configured", and three
documents tell an operator to run
docker compose logs api | grep -i "LDAP auth"
as the FIRST diagnostic when nobody can sign in. Nothing ever logged it. The
grep would have returned silence, during exactly the outage it was written for,
and silence reads as "the API never started" rather than "the API is fine and
the group is misconfigured".
Found while answering a question that the line exists to answer: a required
group had been added to .env, sign-in still worked, and there was no way to
tell whether the group had been checked or the value had simply not been picked
up. (It had not - the file was unsaved. Both readings were correct at the time
they were taken.)
Implemented as a FastAPI lifespan handler. It reports CONFIGURATION only and
opens no connection: startup must not be able to hang on an unreachable domain
controller, and a bind at boot would count against the AD lockout policy for
whatever account it used. ldap_auth.selftest() remains the reachability check -
it validates the certificate without binding, so it cannot contribute to a
lockout either.
Verified by booting the real app under uvicorn and reading the log:
wpsuite.api: LDAP auth enabled - ldaps://prime.local:636, domain prime.local,
CA .../prime-ca-chain.pem, required group: CN=Prime Employees,OU=Prime
Distribution and Security Groups,DC=prime,DC=local
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cody Schaefer
332b74e5de