Follow-up from #109 (spec follow-up item 1, "approach B" from the design).
JWT-secret loading logic is duplicated three times with drifting behavior:
src/lib/auth.ts getJwtSecret() — throws AuthConfigError (login route maps it to a clear 503), dev fallback outside production, 32-char minimum.src/proxy.ts — its own copy, throws plain Error.src/lib/oidc.ts — a third reader for state encryption, plain Error, no min-length check.
Consolidate into a single config module (e.g. src/lib/config/auth-env.ts) that all three consume, using AuthConfigError consistently. Risk notes from the design discussion: this touches the middleware (src/proxy.ts) and files near the npm-package surface, so it needs build:lib + attw verification and careful test coverage; that risk is why it was split out of #109 rather than done there.
Follow-up from #109 (spec follow-up item 1, "approach B" from the design).
JWT-secret loading logic is duplicated three times with drifting behavior:
src/lib/auth.tsgetJwtSecret()— throwsAuthConfigError(login route maps it to a clear 503), dev fallback outside production, 32-char minimum.src/proxy.ts— its own copy, throws plainError.src/lib/oidc.ts— a third reader for state encryption, plainError, no min-length check.Consolidate into a single config module (e.g.
src/lib/config/auth-env.ts) that all three consume, usingAuthConfigErrorconsistently. Risk notes from the design discussion: this touches the middleware (src/proxy.ts) and files near the npm-package surface, so it needsbuild:lib+ attw verification and careful test coverage; that risk is why it was split out of #109 rather than done there.