@payez/next-mvp 4.8.1 → 4.8.2

package/src/auth/password-reset-bridge.ts

@@ -1,98 +1,98 @@
-/**
- * PAY-2121: the fragment bridge on `/`.
- *
- * The IdP's post-verify redirect for a passwordless account lands on
- *   ORIGIN/#password_reset_required=true&reset_token=<token>&email=<addr>
- * - a FRAGMENT, never a query (ProgressiveAuthController.cs:1204-1222). A fresh
- * @payez/next-mvp app has no fragment handling at all, so the user lands on `/`
- * and nothing happens; their reset is lost.
- *
- * This is the PURE half (data in, data out) so a test can execute it without a
- * DOM. The client component (PasswordResetBridge) calls it on mount with
- * `window.location.hash`. The kit's reset surface is the existing
- * `/account-auth/recovery` page, which reads `?email=` and a reset token - so the
- * bridge rewrites the fragment into that surface's OWN query shape and navigates
- * once. It invents no new reset flow.
- *
- * CONTRACT:
- *   '#password_reset_required=true&reset_token=T&email=a%40b.co' -> '/account-auth/recovery?token=T&email=a%40b.co'
- *   any other fragment (no flag, flag != true, no token) -> null (leave `/` alone)
- */
-
-/** The reset surface the bridge hands off to, by its existing path. */
-export const RECOVERY_PATH = '/account-auth/recovery';
-
-/**
- * PAY-2121 (BAPert 70576): the recovery page's ENTRY decision, as a pure function.
- *
- * The bridge now sends a VERIFIED passwordless user to
- *   /account-auth/recovery?token=<reset_token>&email=<addr>
- * with a REAL reset token in hand. If the page then showed its request-a-code
- * step, it would throw that token away and the flow would still dead-end - just
- * one page later. So when a token is present the page must start at the
- * set-password step and submit straight through resetPasswordWithToken.
- *
- *   token present      -> { step: 'set-password', resetToken: <token> }
- *   no token           -> { step: 'initiate',    resetToken: null }   (today's behaviour)
- */
-export function recoveryEntry(
-  token: string | null | undefined,
-  email: string | null | undefined,
-): { step: 'set-password' | 'initiate'; resetToken: string | null; email: string } {
-  const tok = (token ?? '').trim();
-  return {
-    step: tok ? 'set-password' : 'initiate',
-    resetToken: tok || null,
-    email: (email ?? '').trim(),
-  };
-}
-
-/**
- * PAY-2121 (BAPert 70582): the set-password SUBMIT precondition, as a pure
- * function. The old guard was `if (!passwordResetToken || !recoverySession) return;`.
- * Removing the session half (so a deep-linked reset can submit) must NOT let a
- * submit with NO token reach the API carrying an empty token - which is exactly
- * what a guard-less submit would do. This decides it, in one testable place:
- *
- *   resetSubmitTarget(resetToken, sessionEmail, queryEmail):
- *     - no token (after trim)          -> null   (REFUSE: never call the API with an empty token)
- *     - token, session email present   -> { token, email: sessionEmail }
- *     - token, only a query email      -> { token, email: queryEmail }  (the deep-link case)
- *     - token, but NO email anywhere    -> null   (REFUSE: nothing to reset)
- *
- * Returns the exact { token, email } the caller must pass to
- * accountApi.resetPasswordWithToken, or null to refuse BEFORE any request.
- */
-export function resetSubmitTarget(
-  resetToken: string | null | undefined,
-  sessionEmail: string | null | undefined,
-  queryEmail: string | null | undefined,
-): { token: string; email: string } | null {
-  const tok = (resetToken ?? '').trim();
-  if (!tok) return null;
-  const email = ((sessionEmail ?? '').trim() || (queryEmail ?? '').trim());
-  if (!email) return null;
-  return { token: tok, email };
-}
-
-/**
- * The redirect the fragment asks for, or null when the fragment is not a reset
- * request. `hash` is `window.location.hash` (leading '#' optional).
- *
- * Returns null - leaves `/` untouched - when:
- *   - the fragment is empty;
- *   - `password_reset_required` is absent or not exactly 'true';
- *   - no `reset_token` is present (nothing to reset with; not a real link).
- */
-export function passwordResetRedirect(hash: string | null | undefined): string | null {
-  const raw = (hash ?? '').replace(/^#/, '');
-  if (!raw) return null;
-  const params = new URLSearchParams(raw);
-  if (params.get('password_reset_required') !== 'true') return null;
-  const token = params.get('reset_token') ?? '';
-  if (!token) return null;
-  const email = params.get('email') ?? '';
-  const qs = new URLSearchParams({ token });
-  if (email) qs.set('email', email);
-  return `${RECOVERY_PATH}?${qs.toString()}`;
-}
+/**
+ * PAY-2121: the fragment bridge on `/`.
+ *
+ * The IdP's post-verify redirect for a passwordless account lands on
+ *   ORIGIN/#password_reset_required=true&reset_token=<token>&email=<addr>
+ * - a FRAGMENT, never a query (ProgressiveAuthController.cs:1204-1222). A fresh
+ * @payez/next-mvp app has no fragment handling at all, so the user lands on `/`
+ * and nothing happens; their reset is lost.
+ *
+ * This is the PURE half (data in, data out) so a test can execute it without a
+ * DOM. The client component (PasswordResetBridge) calls it on mount with
+ * `window.location.hash`. The kit's reset surface is the existing
+ * `/account-auth/recovery` page, which reads `?email=` and a reset token - so the
+ * bridge rewrites the fragment into that surface's OWN query shape and navigates
+ * once. It invents no new reset flow.
+ *
+ * CONTRACT:
+ *   '#password_reset_required=true&reset_token=T&email=a%40b.co' -> '/account-auth/recovery?token=T&email=a%40b.co'
+ *   any other fragment (no flag, flag != true, no token) -> null (leave `/` alone)
+ */
+
+/** The reset surface the bridge hands off to, by its existing path. */
+export const RECOVERY_PATH = '/account-auth/recovery';
+
+/**
+ * PAY-2121 (BAPert 70576): the recovery page's ENTRY decision, as a pure function.
+ *
+ * The bridge now sends a VERIFIED passwordless user to
+ *   /account-auth/recovery?token=<reset_token>&email=<addr>
+ * with a REAL reset token in hand. If the page then showed its request-a-code
+ * step, it would throw that token away and the flow would still dead-end - just
+ * one page later. So when a token is present the page must start at the
+ * set-password step and submit straight through resetPasswordWithToken.
+ *
+ *   token present      -> { step: 'set-password', resetToken: <token> }
+ *   no token           -> { step: 'initiate',    resetToken: null }   (today's behaviour)
+ */
+export function recoveryEntry(
+  token: string | null | undefined,
+  email: string | null | undefined,
+): { step: 'set-password' | 'initiate'; resetToken: string | null; email: string } {
+  const tok = (token ?? '').trim();
+  return {
+    step: tok ? 'set-password' : 'initiate',
+    resetToken: tok || null,
+    email: (email ?? '').trim(),
+  };
+}
+
+/**
+ * PAY-2121 (BAPert 70582): the set-password SUBMIT precondition, as a pure
+ * function. The old guard was `if (!passwordResetToken || !recoverySession) return;`.
+ * Removing the session half (so a deep-linked reset can submit) must NOT let a
+ * submit with NO token reach the API carrying an empty token - which is exactly
+ * what a guard-less submit would do. This decides it, in one testable place:
+ *
+ *   resetSubmitTarget(resetToken, sessionEmail, queryEmail):
+ *     - no token (after trim)          -> null   (REFUSE: never call the API with an empty token)
+ *     - token, session email present   -> { token, email: sessionEmail }
+ *     - token, only a query email      -> { token, email: queryEmail }  (the deep-link case)
+ *     - token, but NO email anywhere    -> null   (REFUSE: nothing to reset)
+ *
+ * Returns the exact { token, email } the caller must pass to
+ * accountApi.resetPasswordWithToken, or null to refuse BEFORE any request.
+ */
+export function resetSubmitTarget(
+  resetToken: string | null | undefined,
+  sessionEmail: string | null | undefined,
+  queryEmail: string | null | undefined,
+): { token: string; email: string } | null {
+  const tok = (resetToken ?? '').trim();
+  if (!tok) return null;
+  const email = ((sessionEmail ?? '').trim() || (queryEmail ?? '').trim());
+  if (!email) return null;
+  return { token: tok, email };
+}
+
+/**
+ * The redirect the fragment asks for, or null when the fragment is not a reset
+ * request. `hash` is `window.location.hash` (leading '#' optional).
+ *
+ * Returns null - leaves `/` untouched - when:
+ *   - the fragment is empty;
+ *   - `password_reset_required` is absent or not exactly 'true';
+ *   - no `reset_token` is present (nothing to reset with; not a real link).
+ */
+export function passwordResetRedirect(hash: string | null | undefined): string | null {
+  const raw = (hash ?? '').replace(/^#/, '');
+  if (!raw) return null;
+  const params = new URLSearchParams(raw);
+  if (params.get('password_reset_required') !== 'true') return null;
+  const token = params.get('reset_token') ?? '';
+  if (!token) return null;
+  const email = params.get('email') ?? '';
+  const qs = new URLSearchParams({ token });
+  if (email) qs.set('email', email);
+  return `${RECOVERY_PATH}?${qs.toString()}`;
+}

package/src/auth/revocation-fields.ts

@@ -1,16 +1,16 @@
-/**
- * PAY-2339 (BAPert 74633 gap 1): the two revocation fields every viability producer emits, in ONE place so the
- * producers (api-handlers/session/viability.ts and routes/auth/viability.ts, four return sites) cannot drift.
- *
- *   forceInvalid - true ONLY for 'revoked'. An 'unknown' answer is no longer a sign-out verdict.
- *   unavailable  - true when the revocation backend could not answer: 'unknown' and ANY string that is not one of the
- *                  three recognised states. A consumer that reads this JSON (useSessionCheck, makeAuthDecision) holds
- *                  instead of signing the member out. `revocationStatus` itself is emitted unchanged.
- *
- * 'not_configured' is a configuration fault, not an outage: neither field is set for it (unchanged).
- */
-export function revocationFields(status: unknown): { forceInvalid: boolean; unavailable: boolean; revoked: boolean } {
-  const revoked = status === 'revoked';
-  const unavailable = !(status === 'revoked' || status === 'active' || status === 'not_configured');
-  return { forceInvalid: revoked, unavailable, revoked };
-}
+/**
+ * PAY-2339 (BAPert 74633 gap 1): the two revocation fields every viability producer emits, in ONE place so the
+ * producers (api-handlers/session/viability.ts and routes/auth/viability.ts, four return sites) cannot drift.
+ *
+ *   forceInvalid - true ONLY for 'revoked'. An 'unknown' answer is no longer a sign-out verdict.
+ *   unavailable  - true when the revocation backend could not answer: 'unknown' and ANY string that is not one of the
+ *                  three recognised states. A consumer that reads this JSON (useSessionCheck, makeAuthDecision) holds
+ *                  instead of signing the member out. `revocationStatus` itself is emitted unchanged.
+ *
+ * 'not_configured' is a configuration fault, not an outage: neither field is set for it (unchanged).
+ */
+export function revocationFields(status: unknown): { forceInvalid: boolean; unavailable: boolean; revoked: boolean } {
+  const revoked = status === 'revoked';
+  const unavailable = !(status === 'revoked' || status === 'active' || status === 'not_configured');
+  return { forceInvalid: revoked, unavailable, revoked };
+}