@payez/next-mvp 4.1.21 → 4.4.0

package/dist/hooks/useAuthSettings.js

@@ -56,7 +56,14 @@ function useAuthSettings() {
  */
 function useRequires2FA() {
     const authSettings = useAuthSettings();
-    return authSettings?.require2FA ?? true; // Default to true for security
+    // 257255: DELIBERATELY LEFT FAIL-CLOSED, and flagged rather than silently kept.
+    // QAPert proved any hardcoded fallback is wrong in one environment (same client
+    // is require_2fa TRUE on AKS, FALSE on dev-93), so `?? true` is not correct - it
+    // is merely the SAFE direction: it demands more auth rather than less, and
+    // flipping it to false would be fail-OPEN. The genuinely correct answer is to
+    // propagate "unknown" to the caller, which is a breaking signature change
+    // (boolean -> boolean | null) and needs its own decision. Tracked on 257255.
+    return authSettings?.require2FA ?? true;
 }
 /**
  * Hook to get allowed 2FA methods.
@@ -65,7 +72,12 @@ function useRequires2FA() {
  */
 function useAllowed2FAMethods() {
     const authSettings = useAuthSettings();
-    return authSettings?.allowed2FAMethods ?? ['email', 'sms'];
+    // 257255 / v32(a) OFFER NOTHING YOU CANNOT CONFIRM.
+    // Was `?? ['email','sms']` - a fabricated method list rendered whenever the
+    // policy could not be read. On 2026-08-24 that told users to use email+sms
+    // while the database said emailcode+totp. An empty list is the honest answer;
+    // the caller must show "we could not load sign-in options" rather than guess.
+    return authSettings?.allowed2FAMethods ?? [];
 }
 /**
  * Hook to get session timeout settings.

package/dist/hooks/usePublicAuthSettings.d.ts

@@ -7,11 +7,11 @@
 import type { FederatedProvider } from '../types/auth';
 export interface PublicAuthSettings {
     enabledProviders: FederatedProvider[];
-    allowPublicRegistration: boolean;
     allowFederatedLogin: boolean;
-    enablePasswordReset: boolean;
     require2FA: boolean;
     allowed2FAMethods: string[];
+    allowPublicRegistration?: boolean;
+    enablePasswordReset?: boolean;
 }
 export interface UsePublicAuthSettingsResult {
     settings: PublicAuthSettings | null;

package/dist/hooks/usePublicAuthSettings.js

@@ -27,14 +27,19 @@ const PROVIDER_MAP = {
     'microsoft': 'microsoft',
     'azure-ad': 'microsoft',
 };
-const DEFAULT_SETTINGS = {
-    enabledProviders: [],
-    allowPublicRegistration: true,
-    allowFederatedLogin: false,
-    enablePasswordReset: true,
-    require2FA: true,
-    allowed2FAMethods: ['email', 'sms'],
-};
+// 257255 / BAPert ruling v32(a): DEFAULT_SETTINGS DELETED.
+//
+// It was substituted on BOTH failure branches below, so a page kept rendering
+// require2FA=true with methods ['email','sms'] whenever the fetch failed - a
+// FABRICATED AUTHORIZATION POLICY, client-side. Hard-failing the endpoint alone
+// does not fix that: it just moves the lie from the server to the browser.
+//
+// QAPert's measurement makes this a proof rather than a preference: the SAME
+// client is require_2fa=TRUE on AKS and FALSE on dev-93, so any hardcoded
+// fallback is wrong in at least one environment BY CONSTRUCTION.
+//
+// On failure `settings` stays NULL and `error` is set. Callers must render an
+// honest "we could not load sign-in options" state and OFFER NOTHING.
 /**
  * Hook to fetch public auth settings for login/signup pages.
  *
@@ -84,7 +89,12 @@ function usePublicAuthSettings() {
                     });
                 }
                 else {
-                    setSettings(DEFAULT_SETTINGS);
+                    // The endpoint told us it could not read a policy (503 +
+                    // success:false + code). Do NOT invent one - surface it.
+                    const code = data?.error?.code ?? 'POLICY_UNAVAILABLE';
+                    setSettings(null);
+                    setError(new Error(`[auth-settings] ${code}: sign-in options unavailable`));
+                    return;
                 }
                 setError(null);
             }
@@ -93,7 +103,7 @@ function usePublicAuthSettings() {
                     return;
                 console.warn('[usePublicAuthSettings] Failed to fetch settings:', err);
                 setError(err instanceof Error ? err : new Error(String(err)));
-                setSettings(DEFAULT_SETTINGS);
+                setSettings(null); // 257255: never fabricate a policy
             }
             finally {
                 if (mounted) {
@@ -119,13 +129,17 @@ function useFederatedLoginEnabled() {
  * Hook to check if public registration is enabled.
  */
 function usePublicRegistrationEnabled() {
-    const { settings } = usePublicAuthSettings();
-    return settings?.allowPublicRegistration ?? true;
+    // 257255: was `?? true`, which OFFERED a sign-up lane the IDP may forbid -
+    // card 240447 measured exactly that on portal. The field is no longer served
+    // (it was never read from config), so this is now always fail-closed until
+    // the config document carries it.
+    return false;
 }
 /**
  * Hook to check if password reset is enabled.
  */
 function usePasswordResetEnabled() {
-    const { settings } = usePublicAuthSettings();
-    return settings?.enablePasswordReset ?? true;
+    // 257255: was `?? true` and was never read from config. Fail-closed until
+    // the config document carries it.
+    return false;
 }

package/dist/lib/client-key.d.ts

@@ -0,0 +1,61 @@
+/**
+ * ONE resolver for "which client is this request for?" — card 268410.
+ *
+ * THE ASYMMETRY THIS EXISTS TO SURVIVE (measured at source in the IDP,
+ * RequirePayEzUnAuthorizedAttribute.cs):
+ *
+ *   :31-33  int.TryParse succeeds -> Items[PayEzClientId] = numericId; return;   NO existence check
+ *   :41-47  slug -> GetClientIdByNameAsync; if null -> NotFoundResult()          VALIDATED
+ *   :55     no client id at all -> NotFoundResult()
+ *
+ * So a WRONG SLUG 404s loudly. A WRONG NUMERIC is silently accepted and the
+ * request is answered for whatever client that number happens to be. On a
+ * multi-tenant identity service that is a WRONG-TENANT ANSWER, not merely a bug.
+ *
+ * And a stale numeric is the DOCUMENTED NORMAL CASE, not a hypothetical: numeric
+ * ids are environment-specific (card 250596 — 79 was dev-93's id for the SAME
+ * slug, and the merge collapsed 76 into 12), while the slug is stable across
+ * environments.
+ *
+ * WHY THE FALLBACK WAS SILENT: idp-client-config.ts:462 and :669 resolve
+ * `clientSlug: ... ?? ''`. Empty string is FALSY, so the idiom every call site
+ * used —
+ *
+ *     config.clientSlug || String(config.clientId)
+ *
+ * — falls through to the numeric arm whenever the IDP config carries no slug,
+ * with nothing emitted to say it happened. Absence collapsed into a
+ * usable-looking default: the same class the graft's passkey plugin already
+ * called out when `|| ''` made an unset env var look like a valid client_id.
+ *
+ * WHAT THIS DOES **NOT** DO: it does not flip precedence. Slug still wins, the
+ * numeric fallback is still taken, and every deployment that works today keeps
+ * working byte-for-byte. Blanket-flipping these to numeric-first is the
+ * dangerous-looking-safe change the 268410 ruling explicitly holds.
+ *
+ * WHAT IT DOES: it makes the dangerous arm ATTRIBUTABLE. Taking the numeric
+ * fallback now emits a warning naming the call site, so a wrong-tenant answer
+ * is diagnosable in seconds instead of being indistinguishable from a correct
+ * one. That ambiguity is what cost hours on S12.
+ */
+export interface ClientKeySource {
+    clientSlug?: string | null;
+    clientId?: string | number | null;
+}
+export interface ResolvedClientKey {
+    /** The routing key to send as X-Client-Id / client_id, or null if none resolved. */
+    key: string | null;
+    /** True when the environment-specific numeric arm was taken. */
+    usedNumericFallback: boolean;
+}
+/**
+ * Resolve the IDP routing key from a client config.
+ *
+ * `site` names the caller (e.g. 'admin/analytics') and appears verbatim in the
+ * fallback warning — that string is the whole diagnostic value, so pass a real one.
+ *
+ * Pure and non-throwing: callers decide whether a null key is fatal (refuse) or
+ * merely means "omit the header". Both shapes exist in this package and both
+ * are correct for their path.
+ */
+export declare function resolveClientKey(config: ClientKeySource | null | undefined, site: string): ResolvedClientKey;

package/dist/lib/client-key.js

@@ -0,0 +1,72 @@
+"use strict";
+/**
+ * ONE resolver for "which client is this request for?" — card 268410.
+ *
+ * THE ASYMMETRY THIS EXISTS TO SURVIVE (measured at source in the IDP,
+ * RequirePayEzUnAuthorizedAttribute.cs):
+ *
+ *   :31-33  int.TryParse succeeds -> Items[PayEzClientId] = numericId; return;   NO existence check
+ *   :41-47  slug -> GetClientIdByNameAsync; if null -> NotFoundResult()          VALIDATED
+ *   :55     no client id at all -> NotFoundResult()
+ *
+ * So a WRONG SLUG 404s loudly. A WRONG NUMERIC is silently accepted and the
+ * request is answered for whatever client that number happens to be. On a
+ * multi-tenant identity service that is a WRONG-TENANT ANSWER, not merely a bug.
+ *
+ * And a stale numeric is the DOCUMENTED NORMAL CASE, not a hypothetical: numeric
+ * ids are environment-specific (card 250596 — 79 was dev-93's id for the SAME
+ * slug, and the merge collapsed 76 into 12), while the slug is stable across
+ * environments.
+ *
+ * WHY THE FALLBACK WAS SILENT: idp-client-config.ts:462 and :669 resolve
+ * `clientSlug: ... ?? ''`. Empty string is FALSY, so the idiom every call site
+ * used —
+ *
+ *     config.clientSlug || String(config.clientId)
+ *
+ * — falls through to the numeric arm whenever the IDP config carries no slug,
+ * with nothing emitted to say it happened. Absence collapsed into a
+ * usable-looking default: the same class the graft's passkey plugin already
+ * called out when `|| ''` made an unset env var look like a valid client_id.
+ *
+ * WHAT THIS DOES **NOT** DO: it does not flip precedence. Slug still wins, the
+ * numeric fallback is still taken, and every deployment that works today keeps
+ * working byte-for-byte. Blanket-flipping these to numeric-first is the
+ * dangerous-looking-safe change the 268410 ruling explicitly holds.
+ *
+ * WHAT IT DOES: it makes the dangerous arm ATTRIBUTABLE. Taking the numeric
+ * fallback now emits a warning naming the call site, so a wrong-tenant answer
+ * is diagnosable in seconds instead of being indistinguishable from a correct
+ * one. That ambiguity is what cost hours on S12.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.resolveClientKey = resolveClientKey;
+/**
+ * Resolve the IDP routing key from a client config.
+ *
+ * `site` names the caller (e.g. 'admin/analytics') and appears verbatim in the
+ * fallback warning — that string is the whole diagnostic value, so pass a real one.
+ *
+ * Pure and non-throwing: callers decide whether a null key is fatal (refuse) or
+ * merely means "omit the header". Both shapes exist in this package and both
+ * are correct for their path.
+ */
+function resolveClientKey(config, site) {
+    const slug = typeof config?.clientSlug === 'string' ? config.clientSlug.trim() : '';
+    if (slug)
+        return { key: slug, usedNumericFallback: false };
+    const rawNumeric = config?.clientId;
+    // Guard String(undefined) === 'undefined' — a 13-char string that is not a
+    // slug and not a number, so the IDP would 404 it with no hint as to why.
+    if (rawNumeric === null || rawNumeric === undefined) {
+        return { key: null, usedNumericFallback: false };
+    }
+    const numeric = String(rawNumeric).trim();
+    if (!numeric)
+        return { key: null, usedNumericFallback: false };
+    console.warn(`[client-key] ${site}: no clientSlug on the resolved IDP config — falling back to the ` +
+        `NUMERIC client id ${numeric}. Numeric ids are ENVIRONMENT-SPECIFIC and the IDP accepts ` +
+        `them with NO existence check, so if this number is stale for this environment the ` +
+        `request is being answered for the WRONG CLIENT, silently. Card 268410.`);
+    return { key: numeric, usedNumericFallback: true };
+}

package/dist/lib/demo-mode.js

@@ -14,5 +14,6 @@ function isAuthConfigured() {
         return false;
     return !!(process.env.BETTER_AUTH_SECRET ||
         process.env.NEXTAUTH_SECRET ||
-        (process.env.NEXT_CLIENT_ID && process.env.NEXT_CLIENT_PRIVATE_KEY_PEM));
+        // was NEXT_CLIENT_ID - a third name for CLIENT_ID, read only here. Collapsed 2026-08-26.
+        (process.env.CLIENT_ID && process.env.NEXT_CLIENT_PRIVATE_KEY_PEM));
 }

package/dist/lib/ensure-fresh-access-token.js

@@ -311,7 +311,11 @@ async function ensureFreshAccessToken(sessionToken, config, options = {}) {
             bearerKeyId: newKid || session.bearerKeyId,
             authenticationMethods: amrClaims,
             authenticationLevel: acrLevel,
-            mfaVerified: amrClaims.includes('mfa') || session.mfaVerified,
+            // 170007 rule 2 (BAPert ruling on 121350): re-derive from the token
+            // every exchange, never carry forward. See the identical fix + full
+            // rationale in api-handlers/auth/refresh.ts's sessionUpdate — this is
+            // the same defect duplicated at a second call site.
+            mfaVerified: amrClaims.includes('mfa'),
             mfaCompletedAt: decoded?.mfa_time ? parseInt(decoded.mfa_time) * 1000 : session.mfaCompletedAt,
             mfaExpiresAt: decoded?.mfa_expires ? parseInt(decoded.mfa_expires) * 1000 : session.mfaExpiresAt,
             mfaValidityHours: decoded?.mfa_validity_hours ? parseInt(decoded.mfa_validity_hours) : session.mfaValidityHours,

package/dist/lib/idp-client-config.d.ts

@@ -27,8 +27,8 @@ export interface OAuthProviderConfig {
     additionalParams?: Record<string, any>;
 }
 export interface AuthSettings {
-    require2FA: boolean;
-    allowed2FAMethods: string[];
+    require2FA?: boolean;
+    allowed2FAMethods?: string[];
     mfaGracePeriodHours: number;
     mfaRememberDeviceDays: number;
     sessionTimeoutMinutes: number;
@@ -37,6 +37,29 @@ export interface AuthSettings {
     rememberMeDays: number;
     lockoutThreshold: number;
     lockoutDurationMinutes: number;
+    /**
+     * 240447: tenant policy the IDP has always sent and this loader never read.
+     *
+     * The IDP emits these inside `auth_settings` on the internal client-config
+     * response (PayEz.Identity.Api InternalClientConfigController, the
+     * `auth_settings` object: allow_public_registration, allow_social_login,
+     * enable_password_reset — backed by IDPClientSecurityPolicy).
+     * routes/auth/settings was answering with hardcoded `true` literals
+     * carrying the comment "Could come from config.authSettings in future",
+     * so the portal advertised self-serve registration for a tenant whose IDP
+     * forbids it (measured same-client same-minute: IDP
+     * allow_public_registration=FALSE, portal allowPublicRegistration=TRUE).
+     *
+     * OPTIONAL ON PURPOSE — `undefined` must stay distinguishable from
+     * `false`. undefined = the IDP did not tell us (older IDP build, or
+     * auth_settings absent entirely); false = the IDP affirmatively said no.
+     * Collapsing the first into a boolean default is exactly how the previous
+     * hardcoded `true` became a lie that read like a measurement. Consumers
+     * must decide explicitly what an unknown means for them.
+     */
+    allowPublicRegistration?: boolean;
+    allowSocialLogin?: boolean;
+    enablePasswordReset?: boolean;
 }
 export interface BrandingConfig {
     theme?: string;