@payez/next-mvp 4.8.1 → 4.8.3

package/src/routes/auth/settings.ts

@@ -1,181 +1,181 @@
-/**
- * Public Auth Settings Route
- *
- * Returns client auth settings for pre-login pages (signup, login).
- * Does NOT require authentication - these are public client settings.
- *
- * ── 257255: THIS ROUTE USED TO FABRICATE AN AUTHORIZATION POLICY ───────────
- * It returned `success: true` with a hardcoded policy on ANY failure, so a
- * caller could not distinguish "the IDP says X" from "I never reached the
- * IDP". On 2026-08-24 it served require2FA=true / ["email","sms"] for hours
- * while the database said require_2fa=false / ["emailcode","totp"] - wrong
- * about WHETHER 2FA applied and WHICH factors existed, simultaneously and
- * confidently. Six agents spent a night measuring policy with this instrument.
- *
- * Worse, the alarm it swallowed was CORRECT: idp-client-config throws
- * specifically to stop an empty secret reaching betterAuth() and being
- * silently replaced by the PUBLIC DEFAULT_SECRET. This route caught that and
- * returned success.
- *
- * BAPert ruling v32: THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES.
- * QAPert's decisive measurement: the SAME client is require_2fa=TRUE on AKS
- * and FALSE on dev-93, so ANY hardcoded fallback is provably wrong in one
- * environment by construction. There is no safe default because the value is
- * per-client per-environment DATA.
- *
- * The positive control already existed in this package: /api/session/viability
- * surfaces this same fault honestly. These two routes now agree.
- */
-
-import { NextResponse } from 'next/server';
-import { getIDPClientConfig } from '../../lib/idp-client-config';
-import { secretSafeJson } from '../../lib/never-in-response';
-
-export interface PublicAuthSettings {
-    // OAuth providers enabled for this client
-    enabledProviders: string[];
-    allowFederatedLogin: boolean;
-
-    // 2FA settings (public - no secrets)
-    require2FA: boolean;
-    allowed2FAMethods: string[];
-
-    // allowPublicRegistration / enablePasswordReset: OPTIONAL, never invented.
-    //
-    // 257255 removed these outright on the measurement that AuthSettings
-    // "carries no such fields, so they cannot be read today", and left one
-    // instruction: "Re-add them ONLY when the config document actually carries
-    // them." That precondition is now MET. The 240447 fix landed on master
-    // after 257255 was written and taught the loader to read them - AuthSettings
-    // now declares allowPublicRegistration?/enablePasswordReset? and
-    // idp-client-config maps them from auth_settings.allow_public_registration /
-    // enable_password_reset at BOTH construction sites. Re-adding them here is
-    // that instruction being followed, not overridden: deleting them now would
-    // discard a real measurement the loader already performs.
-    //
-    // They are OPTIONAL rather than defaulted, which is the part 240447 got
-    // wrong. Its `?? true` was defended as "preserves today's behaviour ...
-    // cannot regress an older IDP build", but `true` is a PERMISSION CLAIM about
-    // a tenant we did not successfully ask - the same defect class this card
-    // exists to kill, and the exact literal named in its title
-    // (allowPublicRegistration:TRUE). Absent means the IDP did not say; a
-    // consumer must then decide, and cannot mistake a guess for a policy.
-    //
-    // They are NOT validated into a hard 503 like require2FA below, because an
-    // older IDP build may legitimately omit them. Absent-and-honest is correct
-    // there; absent-and-fabricated is not.
-    allowPublicRegistration?: boolean;
-    enablePasswordReset?: boolean;
-}
-
-/** Stable, machine-readable failure codes. Consumers branch on these. */
-export type AuthSettingsErrorCode = 'IDP_UNREACHABLE' | 'IDP_CONFIG_INVALID';
-
-/**
- * Fail closed and LOUD. 503 + success:false + a code, and CRUCIALLY no policy
- * fields at all - not defaults, not partials. A consumer cannot mistake an
- * absent body for an answer, which is exactly the mistake the old shape invited.
- */
-function policyUnavailable(code: AuthSettingsErrorCode, message: string) {
-    return NextResponse.json(
-        { success: false, error: { code, message } },
-        { status: 503, headers: { 'Cache-Control': 'no-store' } },
-    );
-}
-
-/**
- * GET /api/auth/settings
- *
- * Returns public auth settings for the current client, or 503 if the real
- * policy could not be read. It never answers from a default.
- */
-export async function GET() {
-    let config;
-    try {
-        config = await getIDPClientConfig();
-    } catch (error) {
-        // Keep the loud line - it is what finally unmasked this in production.
-        console.error('[AUTH_SETTINGS] Failed to get settings:', error);
-        // The `degraded: true` shape that used to live here (240447) is gone
-        // deliberately. It still answered `success: true` with a full invented
-        // policy and merely LABELLED the guess - which BAPert v32 rules out:
-        // THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES. A flag a consumer may
-        // ignore is not a failure; 503 with no policy fields is.
-        return policyUnavailable(
-            'IDP_UNREACHABLE',
-            'Could not read client configuration from the identity service.',
-        );
-    }
-
-    // ── THE CONDITION IS "DID I READ A VALIDATED POLICY", NOT "DID THE FETCH
-    //    THROW". This distinction is load-bearing and is why the catch above is
-    //    not sufficient on its own (QAPert, and card 257661).
-    //
-    //    getIDPClientConfig caches BEFORE it validates, and the cache-hit paths
-    //    do NOT re-validate. So it can RETURN NORMALLY - no throw, no log line -
-    //    with a config that FAILED validation on the request that cached it.
-    //    Measured on :4702 on 2026-08-24: the loader was throwing 53 times per
-    //    400 log lines while THIS endpoint served a well-formed policy from
-    //    cache. A fix that only handles the throw is bypassed by the cache on
-    //    every request after the first.
-    //
-    //    authSecret is the invariant the loader itself enforces on the fetch
-    //    path (idp-client-config: "LOAD-BEARING - empty must fail here, never
-    //    downstream"). Re-checking it here is what makes a cache hit as safe as
-    //    a fresh read.
-    if (!config?.authSecret) {
-        console.error(
-            '[AUTH_SETTINGS] Refusing to serve policy: config has no authSecret ' +
-            '(likely served from cache before validation - see card 257661).',
-        );
-        return policyUnavailable(
-            'IDP_CONFIG_INVALID',
-            'Client configuration is incomplete; refusing to report a policy.',
-        );
-    }
-
-    // No `??` defaults. If the policy section is absent or malformed we did not
-    // read a policy, and inventing one is the defect this card exists for.
-    const authSettings = config.authSettings;
-    if (
-        !authSettings ||
-        typeof authSettings.require2FA !== 'boolean' ||
-        !Array.isArray(authSettings.allowed2FAMethods)
-    ) {
-        console.error(
-            '[AUTH_SETTINGS] Refusing to serve policy: authSettings absent or malformed.',
-        );
-        return policyUnavailable(
-            'IDP_CONFIG_INVALID',
-            'Client configuration carried no usable auth policy.',
-        );
-    }
-
-    const settings: PublicAuthSettings = {
-        enabledProviders: config.oauthProviders?.filter(p => p.enabled).map(p => p.provider) ?? [],
-
-        // Prefer the EXPLICIT policy field over inferring from the provider
-        // list (240447). Inferring is only a proxy: a tenant can have federated
-        // login switched off while enabled providers are still configured, and
-        // the inference reports `true` for it. Fall back to the inference only
-        // where the IDP does not state the field.
-        allowFederatedLogin:
-            authSettings.allowSocialLogin ??
-            (config.oauthProviders?.some(p => p.enabled) ?? false),
-
-        // Real reads, no `??` literal. Absent stays absent (see interface).
-        allowPublicRegistration: authSettings.allowPublicRegistration,
-        enablePasswordReset: authSettings.enablePasswordReset,
-
-        require2FA: authSettings.require2FA,
-        allowed2FAMethods: authSettings.allowed2FAMethods,
-    };
-
-    // PAY-1529: the public policy is built from an allowlist above; secretSafeJson is the runtime backstop
-    // that answers 500 instead of serving it if a registered secret ever reaches this body anyway.
-    return secretSafeJson(
-        { success: true, data: settings },
-        { headers: { 'Cache-Control': 'no-store' } },
-        'GET /api/auth/settings',
-    );
-}
+/**
+ * Public Auth Settings Route
+ *
+ * Returns client auth settings for pre-login pages (signup, login).
+ * Does NOT require authentication - these are public client settings.
+ *
+ * ── 257255: THIS ROUTE USED TO FABRICATE AN AUTHORIZATION POLICY ───────────
+ * It returned `success: true` with a hardcoded policy on ANY failure, so a
+ * caller could not distinguish "the IDP says X" from "I never reached the
+ * IDP". On 2026-08-24 it served require2FA=true / ["email","sms"] for hours
+ * while the database said require_2fa=false / ["emailcode","totp"] - wrong
+ * about WHETHER 2FA applied and WHICH factors existed, simultaneously and
+ * confidently. Six agents spent a night measuring policy with this instrument.
+ *
+ * Worse, the alarm it swallowed was CORRECT: idp-client-config throws
+ * specifically to stop an empty secret reaching betterAuth() and being
+ * silently replaced by the PUBLIC DEFAULT_SECRET. This route caught that and
+ * returned success.
+ *
+ * BAPert ruling v32: THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES.
+ * QAPert's decisive measurement: the SAME client is require_2fa=TRUE on AKS
+ * and FALSE on dev-93, so ANY hardcoded fallback is provably wrong in one
+ * environment by construction. There is no safe default because the value is
+ * per-client per-environment DATA.
+ *
+ * The positive control already existed in this package: /api/session/viability
+ * surfaces this same fault honestly. These two routes now agree.
+ */
+
+import { NextResponse } from 'next/server';
+import { getIDPClientConfig } from '../../lib/idp-client-config';
+import { secretSafeJson } from '../../lib/never-in-response';
+
+export interface PublicAuthSettings {
+    // OAuth providers enabled for this client
+    enabledProviders: string[];
+    allowFederatedLogin: boolean;
+
+    // 2FA settings (public - no secrets)
+    require2FA: boolean;
+    allowed2FAMethods: string[];
+
+    // allowPublicRegistration / enablePasswordReset: OPTIONAL, never invented.
+    //
+    // 257255 removed these outright on the measurement that AuthSettings
+    // "carries no such fields, so they cannot be read today", and left one
+    // instruction: "Re-add them ONLY when the config document actually carries
+    // them." That precondition is now MET. The 240447 fix landed on master
+    // after 257255 was written and taught the loader to read them - AuthSettings
+    // now declares allowPublicRegistration?/enablePasswordReset? and
+    // idp-client-config maps them from auth_settings.allow_public_registration /
+    // enable_password_reset at BOTH construction sites. Re-adding them here is
+    // that instruction being followed, not overridden: deleting them now would
+    // discard a real measurement the loader already performs.
+    //
+    // They are OPTIONAL rather than defaulted, which is the part 240447 got
+    // wrong. Its `?? true` was defended as "preserves today's behaviour ...
+    // cannot regress an older IDP build", but `true` is a PERMISSION CLAIM about
+    // a tenant we did not successfully ask - the same defect class this card
+    // exists to kill, and the exact literal named in its title
+    // (allowPublicRegistration:TRUE). Absent means the IDP did not say; a
+    // consumer must then decide, and cannot mistake a guess for a policy.
+    //
+    // They are NOT validated into a hard 503 like require2FA below, because an
+    // older IDP build may legitimately omit them. Absent-and-honest is correct
+    // there; absent-and-fabricated is not.
+    allowPublicRegistration?: boolean;
+    enablePasswordReset?: boolean;
+}
+
+/** Stable, machine-readable failure codes. Consumers branch on these. */
+export type AuthSettingsErrorCode = 'IDP_UNREACHABLE' | 'IDP_CONFIG_INVALID';
+
+/**
+ * Fail closed and LOUD. 503 + success:false + a code, and CRUCIALLY no policy
+ * fields at all - not defaults, not partials. A consumer cannot mistake an
+ * absent body for an answer, which is exactly the mistake the old shape invited.
+ */
+function policyUnavailable(code: AuthSettingsErrorCode, message: string) {
+    return NextResponse.json(
+        { success: false, error: { code, message } },
+        { status: 503, headers: { 'Cache-Control': 'no-store' } },
+    );
+}
+
+/**
+ * GET /api/auth/settings
+ *
+ * Returns public auth settings for the current client, or 503 if the real
+ * policy could not be read. It never answers from a default.
+ */
+export async function GET() {
+    let config;
+    try {
+        config = await getIDPClientConfig();
+    } catch (error) {
+        // Keep the loud line - it is what finally unmasked this in production.
+        console.error('[AUTH_SETTINGS] Failed to get settings:', error);
+        // The `degraded: true` shape that used to live here (240447) is gone
+        // deliberately. It still answered `success: true` with a full invented
+        // policy and merely LABELLED the guess - which BAPert v32 rules out:
+        // THE ENDPOINT HARD-FAILS, THE PAGE DEGRADES. A flag a consumer may
+        // ignore is not a failure; 503 with no policy fields is.
+        return policyUnavailable(
+            'IDP_UNREACHABLE',
+            'Could not read client configuration from the identity service.',
+        );
+    }
+
+    // ── THE CONDITION IS "DID I READ A VALIDATED POLICY", NOT "DID THE FETCH
+    //    THROW". This distinction is load-bearing and is why the catch above is
+    //    not sufficient on its own (QAPert, and card 257661).
+    //
+    //    getIDPClientConfig caches BEFORE it validates, and the cache-hit paths
+    //    do NOT re-validate. So it can RETURN NORMALLY - no throw, no log line -
+    //    with a config that FAILED validation on the request that cached it.
+    //    Measured on :4702 on 2026-08-24: the loader was throwing 53 times per
+    //    400 log lines while THIS endpoint served a well-formed policy from
+    //    cache. A fix that only handles the throw is bypassed by the cache on
+    //    every request after the first.
+    //
+    //    authSecret is the invariant the loader itself enforces on the fetch
+    //    path (idp-client-config: "LOAD-BEARING - empty must fail here, never
+    //    downstream"). Re-checking it here is what makes a cache hit as safe as
+    //    a fresh read.
+    if (!config?.authSecret) {
+        console.error(
+            '[AUTH_SETTINGS] Refusing to serve policy: config has no authSecret ' +
+            '(likely served from cache before validation - see card 257661).',
+        );
+        return policyUnavailable(
+            'IDP_CONFIG_INVALID',
+            'Client configuration is incomplete; refusing to report a policy.',
+        );
+    }
+
+    // No `??` defaults. If the policy section is absent or malformed we did not
+    // read a policy, and inventing one is the defect this card exists for.
+    const authSettings = config.authSettings;
+    if (
+        !authSettings ||
+        typeof authSettings.require2FA !== 'boolean' ||
+        !Array.isArray(authSettings.allowed2FAMethods)
+    ) {
+        console.error(
+            '[AUTH_SETTINGS] Refusing to serve policy: authSettings absent or malformed.',
+        );
+        return policyUnavailable(
+            'IDP_CONFIG_INVALID',
+            'Client configuration carried no usable auth policy.',
+        );
+    }
+
+    const settings: PublicAuthSettings = {
+        enabledProviders: config.oauthProviders?.filter(p => p.enabled).map(p => p.provider) ?? [],
+
+        // Prefer the EXPLICIT policy field over inferring from the provider
+        // list (240447). Inferring is only a proxy: a tenant can have federated
+        // login switched off while enabled providers are still configured, and
+        // the inference reports `true` for it. Fall back to the inference only
+        // where the IDP does not state the field.
+        allowFederatedLogin:
+            authSettings.allowSocialLogin ??
+            (config.oauthProviders?.some(p => p.enabled) ?? false),
+
+        // Real reads, no `??` literal. Absent stays absent (see interface).
+        allowPublicRegistration: authSettings.allowPublicRegistration,
+        enablePasswordReset: authSettings.enablePasswordReset,
+
+        require2FA: authSettings.require2FA,
+        allowed2FAMethods: authSettings.allowed2FAMethods,
+    };
+
+    // PAY-1529: the public policy is built from an allowlist above; secretSafeJson is the runtime backstop
+    // that answers 500 instead of serving it if a registered secret ever reaches this body anyway.
+    return secretSafeJson(
+        { success: true, data: settings },
+        { headers: { 'Cache-Control': 'no-store' } },
+        'GET /api/auth/settings',
+    );
+}