- Shipped
- 3 ஆகஸ்ட், 2026 அன்று 3:09 PM UTC
- Author
- Kamo
- Commit
- 3cb118c
SecurityService now gates login on a second factor (§164.312(d)). When one is owed it creates the session but withholds its one-time key, returning a short-lived challenge token instead — a session nobody holds an OTK for is unreachable. This BFF expected an oneTimeKey unconditionally, so an MFA challenge fell into the "no session key received" branch and surfaced to the user as a 500. It now recognises the challenge and passes mfaRequired/mfaToken to the client. /api/login/mfa completes it. From the OTK onward it reuses the existing login route's handoff verbatim — resolve *** from Redis, clear stale cookies, set the new one — because two session-handoff implementations would drift and the one used less often would be the one that rots. A wrong code returns 401 with mfaRequired still true and the same mfaToken: SecurityService deliberately does not consume the challenge on failure, so the user retries the code rather than the password. Forcing a re-password over one typo is how people end up turning MFA off. Inert until someone enrols; nobody has.