@payez/next-mvp 4.5.6 → 4.7.9

package/dist/lib/credential-sign-in-client.js

@@ -0,0 +1,89 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.NO_CODE_REQUEST = exports.MSG_EMAIL_CODE_FAILED = exports.MSG_UNEXPECTED = exports.MSG_CANNOT_SIGN_IN = exports.MSG_RATE_LIMITED = exports.CREDENTIAL_EMAIL_CODE_URL = exports.CREDENTIAL_LOGIN_URL = void 0;
+exports.isEmailShaped = isEmailShaped;
+exports.validateCredentials = validateCredentials;
+exports.credentialSignIn = credentialSignIn;
+exports.requestEmailCode = requestEmailCode;
+/**
+ * PAY-2302 cut 1b: the BROWSER side of the package's credential sign-in, as plain functions so it is testable without a DOM.
+ *
+ * It talks to the routes the app mounts from this package:
+ *   POST /api/auth/admin-login             routes/auth/credential-login             { email, password, code? }
+ *   POST /api/auth/admin-login/email-code  routes/auth/credential-login-email-code  (no body: the browser names no address and no client)
+ *
+ * The result is a closed union so the form cannot invent a state the door never answered. The logic mirrors the portal's
+ * AdminLoginCard.submitLogin (VibeID-Customer-Portal 3d654917) and keeps its rules:
+ *   - 429 is relayed as the door's own sentence; the form never states a window the door did not send.
+ *   - `requiresTwoFactor` moves to the code step and keeps the door's answer (sentVia / codeRequested) so the step names the
+ *     lane that was actually fired (PAY-1576).
+ *   - anything else not `success: true` is an error carrying the door's message, and `offerEmailCode` only when the door set it
+ *     literally true (PAY-2284).
+ */
+const code_step_copy_1 = require("./code-step-copy");
+Object.defineProperty(exports, "NO_CODE_REQUEST", { enumerable: true, get: function () { return code_step_copy_1.NO_CODE_REQUEST; } });
+exports.CREDENTIAL_LOGIN_URL = '/api/auth/admin-login';
+exports.CREDENTIAL_EMAIL_CODE_URL = '/api/auth/admin-login/email-code';
+exports.MSG_RATE_LIMITED = 'Too many attempts. Please try again later.';
+exports.MSG_CANNOT_SIGN_IN = 'Could not sign in. Check your details and try again.';
+exports.MSG_UNEXPECTED = 'Something went wrong signing you in. Please try again.';
+const EMAIL_SHAPE = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;
+function isEmailShaped(v) {
+    return EMAIL_SHAPE.test(v);
+}
+/** Field-level checks before anything is sent. Returns the errors, or null when the input may be submitted. */
+function validateCredentials(email, password) {
+    const errors = {};
+    const trimmed = email.trim();
+    if (!trimmed)
+        errors.email = 'Enter your email address.';
+    else if (!isEmailShaped(trimmed))
+        errors.email = 'Enter a valid email address.';
+    if (!password)
+        errors.password = 'Enter your password.';
+    return errors.email || errors.password ? errors : null;
+}
+function asString(v) {
+    return typeof v === 'string' && v ? v : undefined;
+}
+/** One call to the credential door. `code` is the 2FA code on the second turn; email and password are resubmitted with it. */
+async function credentialSignIn(args, fetchImpl = (input, init) => fetch(input, init)) {
+    try {
+        const res = await fetchImpl(exports.CREDENTIAL_LOGIN_URL, {
+            method: 'POST',
+            headers: { 'Content-Type': 'application/json' },
+            body: JSON.stringify({ email: args.email, password: args.password, code: args.code }),
+        });
+        const body = await res.json().catch(() => null);
+        if (res.status === 429)
+            return { kind: 'rate_limited', message: asString(body?.error) ?? exports.MSG_RATE_LIMITED };
+        if (body?.requiresTwoFactor)
+            return { kind: 'two_factor', codeRequest: (0, code_step_copy_1.readCodeRequest)(body) };
+        if (!res.ok || body?.success !== true) {
+            return { kind: 'error', message: asString(body?.error) ?? exports.MSG_CANNOT_SIGN_IN, offerEmailCode: body?.offerEmailCode === true };
+        }
+        return { kind: 'success' };
+    }
+    catch {
+        return { kind: 'error', message: exports.MSG_UNEXPECTED, offerEmailCode: false };
+    }
+}
+exports.MSG_EMAIL_CODE_FAILED = 'We could not ask for an email code just now. Try again shortly.';
+/** "Email me a code instead": asks the door to email a code. `requested` means asked, never arrived. */
+async function requestEmailCode(fetchImpl = (input, init) => fetch(input, init)) {
+    try {
+        const res = await fetchImpl(exports.CREDENTIAL_EMAIL_CODE_URL, { method: 'POST', credentials: 'include' });
+        const body = await res.json().catch(() => null);
+        if (res.ok && body?.success === true) {
+            return {
+                kind: 'requested',
+                codeRequest: (0, code_step_copy_1.readCodeRequest)(body),
+                devCode: typeof body?.devVerificationCode === 'string' && body.devVerificationCode ? body.devVerificationCode : null,
+            };
+        }
+        return { kind: 'error', message: asString(body?.error) ?? exports.MSG_EMAIL_CODE_FAILED };
+    }
+    catch {
+        return { kind: 'error', message: exports.MSG_EMAIL_CODE_FAILED };
+    }
+}

package/dist/lib/device-id.d.ts

@@ -0,0 +1,37 @@
+/**
+ * Per-browser device identity — card 240566 (QAPert flag 2 on the 9c7a815 review).
+ *
+ * BEFORE: /api/auth/admin-login forwarded ONE hardcoded device-id cookie —
+ * `payez-PayEz-6c8201c35c1b44c9b2e823b36b95a718` — for every caller on the
+ * PUBLIC /sign-in password path. To the IDP's rate limiter and device
+ * fingerprinting, every portal user was literally the same device. Two
+ * consequences, both measured-by-inspection rather than hypothetical:
+ *   1. SHARED-FATE LOCKOUT — one attacker's failed attempts consume the
+ *      throttle budget for every legitimate user at once.
+ *   2. Per-device risk signals are meaningless: "new device" and "trusted
+ *      device" cannot distinguish anybody from anybody.
+ *
+ * The id is a routing/telemetry key, NOT a credential — the IDP must never
+ * grant anything on the strength of it, and nothing here assumes otherwise.
+ * It is client-supplied and therefore client-forgeable; that is inherent to
+ * device-id throttling and is why it supplements, never replaces, the
+ * identifier- and IP-scoped limits on the IDP side.
+ *
+ * Shape is fixed by what the IDP already accepts from
+ * createLoginHandler: `payez-PayEz-<32 lowercase hex>`.
+ */
+export declare const DEVICE_ID_HEADER = "X-Device-Id";
+export declare const DEVICE_ID_PATTERN: RegExp;
+/** True for a well-formed device id. Used on BOTH sides of the wire. */
+export declare function isValidDeviceId(value: string | null | undefined): value is string;
+/**
+ * The stable per-browser device id, minted once and persisted.
+ *
+ * Browser-only. Persistence is best-effort: private windows, disabled site
+ * data and storage-quota failures all throw on access, so every read and
+ * write is guarded. A browser that cannot persist still gets a VALID id for
+ * this call — it simply looks like a new device each time, which is the
+ * honest answer for a client that refuses to be remembered, and is still
+ * strictly better than every user sharing one identity.
+ */
+export declare function getDeviceId(): string;

package/dist/lib/device-id.js

@@ -0,0 +1,70 @@
+"use strict";
+/**
+ * Per-browser device identity — card 240566 (QAPert flag 2 on the 9c7a815 review).
+ *
+ * BEFORE: /api/auth/admin-login forwarded ONE hardcoded device-id cookie —
+ * `payez-PayEz-6c8201c35c1b44c9b2e823b36b95a718` — for every caller on the
+ * PUBLIC /sign-in password path. To the IDP's rate limiter and device
+ * fingerprinting, every portal user was literally the same device. Two
+ * consequences, both measured-by-inspection rather than hypothetical:
+ *   1. SHARED-FATE LOCKOUT — one attacker's failed attempts consume the
+ *      throttle budget for every legitimate user at once.
+ *   2. Per-device risk signals are meaningless: "new device" and "trusted
+ *      device" cannot distinguish anybody from anybody.
+ *
+ * The id is a routing/telemetry key, NOT a credential — the IDP must never
+ * grant anything on the strength of it, and nothing here assumes otherwise.
+ * It is client-supplied and therefore client-forgeable; that is inherent to
+ * device-id throttling and is why it supplements, never replaces, the
+ * identifier- and IP-scoped limits on the IDP side.
+ *
+ * Shape is fixed by what the IDP already accepts from
+ * createLoginHandler: `payez-PayEz-<32 lowercase hex>`.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DEVICE_ID_PATTERN = exports.DEVICE_ID_HEADER = void 0;
+exports.isValidDeviceId = isValidDeviceId;
+exports.getDeviceId = getDeviceId;
+exports.DEVICE_ID_HEADER = 'X-Device-Id';
+exports.DEVICE_ID_PATTERN = /^payez-PayEz-[0-9a-f]{32}$/;
+const STORAGE_KEY = 'payez.device-id';
+/** True for a well-formed device id. Used on BOTH sides of the wire. */
+function isValidDeviceId(value) {
+    return typeof value === 'string' && exports.DEVICE_ID_PATTERN.test(value);
+}
+function mint() {
+    const bytes = new Uint8Array(16);
+    crypto.getRandomValues(bytes);
+    const hex = Array.from(bytes, b => b.toString(16).padStart(2, '0')).join('');
+    return `payez-PayEz-${hex}`;
+}
+/**
+ * The stable per-browser device id, minted once and persisted.
+ *
+ * Browser-only. Persistence is best-effort: private windows, disabled site
+ * data and storage-quota failures all throw on access, so every read and
+ * write is guarded. A browser that cannot persist still gets a VALID id for
+ * this call — it simply looks like a new device each time, which is the
+ * honest answer for a client that refuses to be remembered, and is still
+ * strictly better than every user sharing one identity.
+ */
+function getDeviceId() {
+    if (typeof window === 'undefined')
+        return mint();
+    try {
+        const existing = window.localStorage.getItem(STORAGE_KEY);
+        if (isValidDeviceId(existing))
+            return existing;
+    }
+    catch {
+        return mint();
+    }
+    const minted = mint();
+    try {
+        window.localStorage.setItem(STORAGE_KEY, minted);
+    }
+    catch {
+        /* not persistable — the minted id is still returned and used for this call */
+    }
+    return minted;
+}

package/dist/lib/lock-window.d.ts

@@ -0,0 +1,29 @@
+/**
+ * PAY-1608: a 2FA lock's window, stated as the IdP enforces it. Never a hard-coded "15 minutes".
+ *
+ * Core answers every 2FA lock with 429 code "locked" plus Retry-After: MfaController.SecondFactorLocked sends the
+ * full lockout (900), and VerifyTotp sends what is LEFT of the lock. The portal used to hard-code "locked for 15
+ * minutes" in three places (verify-code-copy.ts, twofa-rejection.ts, and the next-mvp BFF), which was true only
+ * while every lock was exactly 15 minutes and the user had just tripped it.
+ *
+ * The window arrives in one of two ways:
+ *   - Door A (verify-code): next-mvp >= 4.5.2 relays it in the BFF body as `retryAfterSeconds` (a number).
+ *   - Door B (admin-login): this route reads the IdP's Retry-After header itself.
+ * With no window, the sentence states NO number rather than a guessed one.
+ *
+ * Dependency-free on purpose: the verify-code page (client) and the admin-login route (server) both use it, and
+ * the chain gate executes it directly.
+ */
+/** A positive whole number of seconds from the BFF body, or undefined. Anything else - a string, 0, NaN - is dropped. */
+export declare function lockSecondsFromBody(value: unknown): number | undefined;
+/** A Retry-After header as whole seconds. ONE implementation: the package's lib/retry-after (the portal copy was the same rule). */
+export { parseRetryAfterSeconds } from './retry-after';
+/**
+ * The window in words, rounded UP so the user is never told a shorter wait than the IdP enforces:
+ * 900 -> "15 minutes", 61 -> "2 minutes", 60 -> "1 minute", 45 -> "45 seconds", 7200 -> "2 hours".
+ */
+export declare function formatLockWindow(seconds: number | undefined): string | undefined;
+/** The sentence for a lock whose window was NOT sent. It says even a correct code is refused, and states no number. */
+export declare const LOCKED_NO_WINDOW = "Too many incorrect codes. Verification is locked for now - even a correct code is refused until the lock ends. Wait before entering another code.";
+/** The locked sentence: the IdP's real window when it sent one, otherwise LOCKED_NO_WINDOW. */
+export declare function lockedSentence(seconds?: number): string;

package/dist/lib/lock-window.js

@@ -0,0 +1,53 @@
+"use strict";
+/**
+ * PAY-1608: a 2FA lock's window, stated as the IdP enforces it. Never a hard-coded "15 minutes".
+ *
+ * Core answers every 2FA lock with 429 code "locked" plus Retry-After: MfaController.SecondFactorLocked sends the
+ * full lockout (900), and VerifyTotp sends what is LEFT of the lock. The portal used to hard-code "locked for 15
+ * minutes" in three places (verify-code-copy.ts, twofa-rejection.ts, and the next-mvp BFF), which was true only
+ * while every lock was exactly 15 minutes and the user had just tripped it.
+ *
+ * The window arrives in one of two ways:
+ *   - Door A (verify-code): next-mvp >= 4.5.2 relays it in the BFF body as `retryAfterSeconds` (a number).
+ *   - Door B (admin-login): this route reads the IdP's Retry-After header itself.
+ * With no window, the sentence states NO number rather than a guessed one.
+ *
+ * Dependency-free on purpose: the verify-code page (client) and the admin-login route (server) both use it, and
+ * the chain gate executes it directly.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.LOCKED_NO_WINDOW = exports.parseRetryAfterSeconds = void 0;
+exports.lockSecondsFromBody = lockSecondsFromBody;
+exports.formatLockWindow = formatLockWindow;
+exports.lockedSentence = lockedSentence;
+/** A positive whole number of seconds from the BFF body, or undefined. Anything else - a string, 0, NaN - is dropped. */
+function lockSecondsFromBody(value) {
+    return typeof value === 'number' && Number.isFinite(value) && value > 0 ? Math.ceil(value) : undefined;
+}
+/** A Retry-After header as whole seconds. ONE implementation: the package's lib/retry-after (the portal copy was the same rule). */
+var retry_after_1 = require("./retry-after");
+Object.defineProperty(exports, "parseRetryAfterSeconds", { enumerable: true, get: function () { return retry_after_1.parseRetryAfterSeconds; } });
+/**
+ * The window in words, rounded UP so the user is never told a shorter wait than the IdP enforces:
+ * 900 -> "15 minutes", 61 -> "2 minutes", 60 -> "1 minute", 45 -> "45 seconds", 7200 -> "2 hours".
+ */
+function formatLockWindow(seconds) {
+    if (typeof seconds !== 'number' || !Number.isFinite(seconds) || seconds <= 0)
+        return undefined;
+    const plural = (n, unit) => `${n} ${unit}${n === 1 ? '' : 's'}`;
+    if (seconds < 60)
+        return plural(Math.ceil(seconds), 'second');
+    const minutes = Math.ceil(seconds / 60);
+    if (minutes < 120)
+        return plural(minutes, 'minute');
+    return plural(Math.ceil(minutes / 60), 'hour');
+}
+/** The sentence for a lock whose window was NOT sent. It says even a correct code is refused, and states no number. */
+exports.LOCKED_NO_WINDOW = 'Too many incorrect codes. Verification is locked for now - even a correct code is refused until the lock ends. Wait before entering another code.';
+/** The locked sentence: the IdP's real window when it sent one, otherwise LOCKED_NO_WINDOW. */
+function lockedSentence(seconds) {
+    const window = formatLockWindow(seconds);
+    return window
+        ? `Too many incorrect codes. Verification is locked for ${window} - wait before entering another code.`
+        : exports.LOCKED_NO_WINDOW;
+}

package/dist/lib/login-error-message.d.ts

@@ -0,0 +1,18 @@
+/**
+ * PAY-2319 (4.7.2): what the login page SAYS for an `?error=` / `?oauth_error=` code, as pure functions so a test can
+ * execute them (the page is a client component and effects do not run in a static render).
+ *
+ * 4.7.1 mapped these codes in an effect that called setLoginError, but the page never RENDERED loginError (it only fed the
+ * loading gate), so no sentence was ever shown (NightHawk's walk, 73801, W1). Now that the text is displayed, a raw code from
+ * the URL must NOT be echoed: `/account-auth/login?error=<anything an attacker types>` would otherwise print attacker-chosen
+ * text on the login page (content spoofing / phishing). Known codes get their sentence; anything else gets one generic
+ * sentence; nothing from the URL is ever shown verbatim.
+ */
+export declare const GENERIC_LOGIN_ERROR = "We could not sign you in. Please try again.";
+/**
+ * The sentence for `?error=<code>`, or null when nothing should be shown.
+ * SessionExpired is a normal event (not an error) and shows nothing; an absent/empty code shows nothing.
+ */
+export declare function friendlyLoginError(code: string | null | undefined): string | null;
+/** `?oauth_error=<provider>`: only a plain provider-like slug is echoed (capitalised); anything else is the generic sentence. */
+export declare function oauthFailureMessage(provider: string | null | undefined): string | null;

package/dist/lib/login-error-message.js

@@ -0,0 +1,47 @@
+"use strict";
+/**
+ * PAY-2319 (4.7.2): what the login page SAYS for an `?error=` / `?oauth_error=` code, as pure functions so a test can
+ * execute them (the page is a client component and effects do not run in a static render).
+ *
+ * 4.7.1 mapped these codes in an effect that called setLoginError, but the page never RENDERED loginError (it only fed the
+ * loading gate), so no sentence was ever shown (NightHawk's walk, 73801, W1). Now that the text is displayed, a raw code from
+ * the URL must NOT be echoed: `/account-auth/login?error=<anything an attacker types>` would otherwise print attacker-chosen
+ * text on the login page (content spoofing / phishing). Known codes get their sentence; anything else gets one generic
+ * sentence; nothing from the URL is ever shown verbatim.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.GENERIC_LOGIN_ERROR = void 0;
+exports.friendlyLoginError = friendlyLoginError;
+exports.oauthFailureMessage = oauthFailureMessage;
+exports.GENERIC_LOGIN_ERROR = 'We could not sign you in. Please try again.';
+const KNOWN = {
+    TwoFactorTimeout: 'Your verification step timed out before the code was confirmed. Please sign in again.',
+    AUTHORIZE_RESUME_REFUSED: 'That sign-in request could not be continued. Please sign in again.',
+    ServiceUnavailable: 'Authentication service is temporarily unavailable. Please try again in a few minutes.',
+    CredentialsSignin: 'Invalid email or password. Please try again.',
+};
+/**
+ * The sentence for `?error=<code>`, or null when nothing should be shown.
+ * SessionExpired is a normal event (not an error) and shows nothing; an absent/empty code shows nothing.
+ */
+function friendlyLoginError(code) {
+    if (typeof code !== 'string' || code === '')
+        return null;
+    if (code === 'SessionExpired')
+        return null;
+    if (Object.prototype.hasOwnProperty.call(KNOWN, code))
+        return KNOWN[code];
+    // The old raw-JSON parse failures the middleware/proxy could bounce here:
+    if (code.startsWith('Unexpected token') || code.includes('not valid JSON')) {
+        return 'An authentication error occurred. Please try signing in again.';
+    }
+    return exports.GENERIC_LOGIN_ERROR;
+}
+/** `?oauth_error=<provider>`: only a plain provider-like slug is echoed (capitalised); anything else is the generic sentence. */
+function oauthFailureMessage(provider) {
+    if (typeof provider !== 'string' || provider === '')
+        return null;
+    if (!/^[a-z][a-z0-9_-]{0,31}$/i.test(provider))
+        return exports.GENERIC_LOGIN_ERROR;
+    return `${provider.charAt(0).toUpperCase()}${provider.slice(1)} sign-in did not complete. Please try again.`;
+}

package/dist/lib/twofa-rejection.d.ts

@@ -0,0 +1,20 @@
+export interface TwofaLaneResult {
+    status: number;
+    body: string;
+    /** PAY-2284: which lane this answer came from, so a fault in the TOTP/SMS lane can offer the email lane (never offered when the EMAIL lane is the one that faulted). */
+    lane?: 'totp' | 'sms' | 'email';
+    /** PAY-1608: this lane's Retry-After header, as received. */
+    retryAfter?: string | null;
+}
+export interface TwofaRejection {
+    status: 400 | 429 | 502;
+    error: string;
+    retryAfter?: number;
+    /**
+     * PAY-2284: true when the authenticator (or text) lane failed on OUR side and the emailed-code lane has not faulted. The sign-in
+     * card then shows a real "Email me a code instead" action. Before this, the copy said "use another sign-in method" and the screen
+     * offered none, and a TOTP holder - for whom the door sends NOTHING at sign-in - was stuck (Jon, 12 Oct, dev-93 key version 57).
+     */
+    offerEmailCode?: true;
+}
+export declare function classifyTwofaRejection(lanes: TwofaLaneResult[], retryAfterHeader?: string | null): TwofaRejection;

package/dist/lib/twofa-rejection.js

@@ -0,0 +1,73 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.classifyTwofaRejection = classifyTwofaRejection;
+/**
+ * Door B (/api/auth/admin-login) twofa verify: what to tell the user when every lane refused.
+ *
+ * Classification is by the MOST BLOCKING outcome across lanes (268121 ruling), in this order:
+ *   429 from the IdP, or any lane answering code `locked`  -> 429 lockout (PAY-903)
+ *   any 5xx, or a lane answering code server_error / service_unavailable (PAY-1589) -> 502 "our side, not your code"
+ *   otherwise                                              -> 400 wrong / expired code
+ *
+ * PAY-903: MfaController.VerifyTotp returns 400 {message, code:"locked"} for a 15-minute lockout
+ * (MfaTotpService ErrorCode "locked"). Status-only classification read that as "wrong code, try again" -
+ * coaching a locked-out user to spend attempts. The body is inspected for EVERY lane, because with lane
+ * order [totp, email] the last response is the email lane's and never carries the TOTP lockout.
+ * Disclosing the lockout here is safe: this step is post-password (the caller already proved the account).
+ *
+ * PAY-1608: the lockout states the LOCKED LANE's own Retry-After (Core sends one on every 2FA lock; VerifyTotp sends
+ * what is LEFT of it). It used to hard-code 15 minutes / 900 s. With no usable header, no number is stated and
+ * `retryAfter` is omitted rather than invented.
+ */
+const lock_window_1 = require("./lock-window");
+/** Every code the IdP body carries: flat {code}, envelope {error:{code}}, or {error:{details:{code}}}. */
+function laneCodes(body) {
+    try {
+        const j = JSON.parse(body);
+        if (!j || typeof j !== 'object')
+            return [];
+        const err = (j.error && typeof j.error === 'object' ? j.error : null);
+        const details = (err?.details && typeof err.details === 'object' ? err.details : null);
+        return [j.code, err?.code, details?.code].filter((c) => typeof c === 'string').map((c) => c.toLowerCase());
+    }
+    catch {
+        return [];
+    }
+}
+function classifyTwofaRejection(lanes, retryAfterHeader) {
+    const lockedLane = lanes.find((l) => laneCodes(l.body).includes('locked'));
+    if (lockedLane) {
+        const secs = (0, lock_window_1.parseRetryAfterSeconds)(lockedLane.retryAfter);
+        return { status: 429, error: (0, lock_window_1.lockedSentence)(secs), ...(secs ? { retryAfter: secs } : {}) };
+    }
+    if (lanes.some((l) => l.status === 429)) {
+        const parsed = retryAfterHeader ? parseInt(retryAfterHeader, 10) : NaN;
+        return {
+            status: 429,
+            error: 'Too many attempts. Your code is still valid - wait before trying again.',
+            retryAfter: Number.isFinite(parsed) && parsed > 0 ? parsed : 60,
+        };
+    }
+    // PAY-1589: an IdP-side fault that arrives as 400 + code (TOTP secret cannot be decrypted -> server_error;
+    // replay store down -> service_unavailable). It is not the user's code and does not count toward the lockout,
+    // so calling it "not right" sends them round a loop that cannot succeed. Email may still work, so say so.
+    const faulted = (l) => laneCodes(l.body).some((c) => c === 'server_error' || c === 'service_unavailable');
+    if (lanes.some(faulted)) {
+        const emailLaneFaulted = lanes.some((l) => l.lane === 'email' && (faulted(l) || l.status >= 500));
+        const offer = !emailLaneFaulted && lanes.some((l) => faulted(l) && (l.lane === 'totp' || l.lane === 'sms'));
+        return {
+            status: 502,
+            error: offer
+                ? 'We could not check your code just now - this is a problem on our side, not with your code. You can have us email you a code instead.'
+                : 'We could not check your code just now - this is a problem on our side, not with your code. Try again shortly.',
+            ...(offer ? { offerEmailCode: true } : {}),
+        };
+    }
+    if (lanes.some((l) => l.status >= 500)) {
+        return {
+            status: 502,
+            error: 'We could not check your code just now - this is a problem on our side, not with your code. Try again shortly.',
+        };
+    }
+    return { status: 400, error: 'That code is not right or has expired. Try again.' };
+}

package/dist/middleware/create-middleware.d.ts

@@ -99,6 +99,19 @@ export interface MvpMiddlewareOptions {
     bypassPaths?: string[];
     /** Paths exempt from RBAC checks (auth still enforced, just no page-permission check) */
     rbacExemptPaths?: string[];
+    /**
+     * PAY-2218 - send a page's session-ending redirect through the session-reset ROUTE instead of clearing the
+     * cookies in the middleware response. Next strips the router's prefetch headers before middleware runs
+     * (15.5.x and 16.x; 16.2.x restores them only with `skipProxyUrlNormalize: true`), so a middleware clear also
+     * fires on a router PREFETCH and signs the user out of a page they never opened. The route sees those headers.
+     *
+     * Requires the app to mount the route:  app/api/auth/session-reset/route.ts
+     *     export { GET } from '@payez/next-mvp/routes/auth/session-reset';
+     * `true` uses that default path; a string names another mount point under /api/auth/ (middleware bypasses it).
+     * Needs BETTER_AUTH_SECRET (or NEXTAUTH_SECRET) to sign the hand-off; without one the direct clear is kept and
+     * an error is logged once. Default: off (the direct clear), because an unmounted route would 404 every sign-out.
+     */
+    sessionResetRoute?: boolean | string;
     /**
      * PAY-1882 step 4 - how this app treats a producer that reports the session's
      * revocation status as `'unknown'` (a Vibe read that FAILED: non-OK, timeout,
@@ -123,6 +136,17 @@ export interface MvpMiddlewareOptions {
      * is signed out for not implementing the check).
      */
     revocationFailMode?: 'closed' | 'open';
+    /**
+     * PAY-2302 cut 1c (BAPert 73585): this app has NO revocation source - for example a development environment
+     * provisioned without a vibe client id / HMAC key - and says so EXPLICITLY. Under it a viability answer of
+     * `revocationStatus: 'not_configured'` is viable, and a loud warning is logged once at startup.
+     *
+     * It relaxes ONLY 'not_configured'. 'unknown' (a revocation read that FAILED) and 'revoked' stay closed whatever
+     * `revocationFailMode` says, and the default (option absent) is unchanged: 'not_configured' fails closed, because
+     * for an app that HAS a vibe client it means a misconfiguration (BAPert 66356). Do not use this to paper over a
+     * misconfigured production app; remove it when the environment has a vibe client + HMAC key.
+     */
+    noRevocationSource?: boolean;
 }
 /**
  * PAY-2136 Rule A: a speculative request (router prefetch) must NEVER mutate cookies.
@@ -153,4 +177,4 @@ export declare function decideForceInvalid(data: {
     revocationStatus?: unknown;
     forceInvalid?: unknown;
     revoked?: unknown;
-}, revocationFailMode: 'closed' | 'open'): boolean;
+}, revocationFailMode: 'closed' | 'open', noRevocationSource?: boolean): boolean;