@payez/next-mvp 4.1.11 → 4.1.20

package/dist/api-handlers/account/profile.d.ts

@@ -1,3 +1,41 @@
 import { NextRequest, NextResponse } from 'next/server';
+/**
+ * Account Profile API Handler
+ *
+ * GET /api/account/profile  - Get user profile
+ * PUT /api/account/profile  - Update user profile
+ *
+ * WHY THIS WAS REWRITTEN (2026-08-02, QAPert defect #7)
+ * Reported as "/api/account/profile 401s on the same cookie masked-info
+ * accepts (200)". Two endpoints disagreeing about one cookie meant two auth
+ * implementations, and they were:
+ *
+ *   masked-info.ts  idpFetchJSON(req, ...)           resolves the caller's token
+ *                                                    from the server-side session
+ *   profile.ts      req.headers.get('authorization') required an INBOUND bearer
+ *
+ * A browser sends a session COOKIE and no Authorization header, so the old
+ * profile.ts 401'd EVERY browser request by construction. Nothing was revoked
+ * and no token was stale — the handler demanded a credential the app does not
+ * use.
+ *
+ * THE OLD AUTH CHECK WAS A VENEER. It tested that the header was PRESENT, never
+ * that it was valid, then forwarded it upstream unexamined. Any string at all
+ * got past it and the IDP did the real work. It looked like enforcement and
+ * enforced nothing.
+ *
+ * WHAT THE WORKAROUND COST US: consumers could not call this with a cookie, so
+ * the graft's useProfile hook fetched the raw IDP access token from
+ * /api/session/idp-token INTO BROWSER JAVASCRIPT and re-sent it as a bearer.
+ * That defeats the reason idpFetchJSON exists — it keeps the token server-side
+ * precisely so client-side script can never hold it. The bearer-only handler
+ * did not merely fail; it pushed its callers into exposing the token.
+ *
+ * Switching to idpFetchJSON makes the cookie work, so the hook's token round
+ * trip can be deleted and /api/session/idp-token drops to a single deliberate
+ * caller: the jwt-inspect debug page.
+ *
+ * @package @payez/next-mvp
+ */
 export declare function GET(req: NextRequest): Promise<NextResponse<any>>;
 export declare function PUT(req: NextRequest): Promise<NextResponse<any>>;

package/dist/api-handlers/account/profile.js

@@ -3,61 +3,89 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.GET = GET;
 exports.PUT = PUT;
 const server_1 = require("next/server");
+const idp_fetch_1 = require("../../lib/idp-fetch");
+const env_1 = require("../../config/env");
 /**
  * Account Profile API Handler
- * Simple proxy to IDP profile endpoint
  *
- * GET /api/account/profile - Get user profile
- * PUT /api/account/profile - Update user profile
+ * GET /api/account/profile  - Get user profile
+ * PUT /api/account/profile  - Update user profile
+ *
+ * WHY THIS WAS REWRITTEN (2026-08-02, QAPert defect #7)
+ * Reported as "/api/account/profile 401s on the same cookie masked-info
+ * accepts (200)". Two endpoints disagreeing about one cookie meant two auth
+ * implementations, and they were:
+ *
+ *   masked-info.ts  idpFetchJSON(req, ...)           resolves the caller's token
+ *                                                    from the server-side session
+ *   profile.ts      req.headers.get('authorization') required an INBOUND bearer
+ *
+ * A browser sends a session COOKIE and no Authorization header, so the old
+ * profile.ts 401'd EVERY browser request by construction. Nothing was revoked
+ * and no token was stale — the handler demanded a credential the app does not
+ * use.
+ *
+ * THE OLD AUTH CHECK WAS A VENEER. It tested that the header was PRESENT, never
+ * that it was valid, then forwarded it upstream unexamined. Any string at all
+ * got past it and the IDP did the real work. It looked like enforcement and
+ * enforced nothing.
+ *
+ * WHAT THE WORKAROUND COST US: consumers could not call this with a cookie, so
+ * the graft's useProfile hook fetched the raw IDP access token from
+ * /api/session/idp-token INTO BROWSER JAVASCRIPT and re-sent it as a bearer.
+ * That defeats the reason idpFetchJSON exists — it keeps the token server-side
+ * precisely so client-side script can never hold it. The bearer-only handler
+ * did not merely fail; it pushed its callers into exposing the token.
+ *
+ * Switching to idpFetchJSON makes the cookie work, so the hook's token round
+ * trip can be deleted and /api/session/idp-token drops to a single deliberate
+ * caller: the jwt-inspect debug page.
+ *
+ * @package @payez/next-mvp
  */
-function getIdpUrl() {
-    const url = process.env.IDP_URL;
-    if (!url) {
-        throw new Error('[IDP_URL] FATAL: IDP_URL environment variable is REQUIRED.');
-    }
-    return url;
-}
 async function GET(req) {
-    const IDP_URL = getIdpUrl();
-    const authHeader = req.headers.get('authorization');
-    if (!authHeader) {
-        return server_1.NextResponse.json({ success: false, error: { code: 'UNAUTHORIZED', message: 'Authentication required' } }, { status: 401 });
-    }
-    try {
-        const upstream = await fetch(`${IDP_URL}/api/Account/profile`, {
-            method: 'GET',
-            headers: {
-                'Content-Type': 'application/json',
-                'Authorization': authHeader,
+    const result = await (0, idp_fetch_1.idpFetchJSON)(req, `${env_1.ENV_CONFIG.IDP_URL}/api/Account/profile`, {
+        method: 'GET',
+        headers: { 'Content-Type': 'application/json' },
+    });
+    if (!result.ok) {
+        return server_1.NextResponse.json({
+            success: false,
+            error: {
+                code: 'UPSTREAM_SERVICE_ERROR',
+                message: result.json?.message || 'Failed to fetch profile',
+                status: result.status,
             },
-        });
-        const data = await upstream.json().catch(() => ({}));
-        return server_1.NextResponse.json(data, { status: upstream.status });
-    }
-    catch (error) {
-        return server_1.NextResponse.json({ success: false, error: { code: 'UPSTREAM_ERROR', message: 'Failed to fetch profile' } }, { status: 500 });
+            meta: { attemptedRefresh: result.attemptedRefresh },
+        }, { status: result.status });
     }
+    return server_1.NextResponse.json(result.json, { status: 200 });
 }
 async function PUT(req) {
-    const IDP_URL = getIdpUrl();
-    const authHeader = req.headers.get('authorization');
-    if (!authHeader) {
-        return server_1.NextResponse.json({ success: false, error: { code: 'UNAUTHORIZED', message: 'Authentication required' } }, { status: 401 });
-    }
+    let body = '{}';
     try {
-        const body = await req.text();
-        const upstream = await fetch(`${IDP_URL}/api/Account/profile`, {
-            method: 'PUT',
-            headers: {
-                'Content-Type': 'application/json',
-                'Authorization': authHeader,
-            },
-            body,
-        });
-        const data = await upstream.json().catch(() => ({}));
-        return server_1.NextResponse.json(data, { status: upstream.status });
+        const raw = await req.text();
+        if (raw && raw.trim().length > 0)
+            body = raw;
     }
-    catch (error) {
-        return server_1.NextResponse.json({ success: false, error: { code: 'UPSTREAM_ERROR', message: 'Failed to update profile' } }, { status: 500 });
+    catch {
+        // Empty body is valid here; the IDP validates the payload.
+    }
+    const result = await (0, idp_fetch_1.idpFetchJSON)(req, `${env_1.ENV_CONFIG.IDP_URL}/api/Account/profile`, {
+        method: 'PUT',
+        headers: { 'Content-Type': 'application/json' },
+        body,
+    });
+    if (!result.ok) {
+        return server_1.NextResponse.json({
+            success: false,
+            error: {
+                code: 'UPSTREAM_SERVICE_ERROR',
+                message: result.json?.message || 'Failed to update profile',
+                status: result.status,
+            },
+            meta: { attemptedRefresh: result.attemptedRefresh },
+        }, { status: result.status });
     }
+    return server_1.NextResponse.json(result.json, { status: 200 });
 }

package/dist/api-handlers/account/recovery/send-code.d.ts

@@ -1,2 +1,35 @@
 import { NextRequest, NextResponse } from 'next/server';
+/**
+ * Account recovery — send-code
+ *
+ * WHY THIS WAS REWRITTEN (2026-08-02, swept out of QAPert defect #7)
+ * This handler read the caller's bearer straight off the inbound request:
+ *
+ *     const auth  = req.headers.get('authorization') || '';
+ *     const token = auth.startsWith('Bearer ') ? auth.slice(7) : '';
+ *     ... headers: { 'Authorization': `Bearer ${token}` }
+ *
+ * Browsers send a session COOKIE and no Authorization header, so `token` was
+ * ALWAYS the empty string and this always called the IDP with a literal
+ * "Bearer " and nothing after it.
+ *
+ * THAT IS WORSE THAN THE profile.ts VERSION OF THIS BUG, in two ways:
+ *
+ *   1. profile.ts at least 401'd when the header was missing. This one has no
+ *      check at all — `|| ''` swallows the absence — so it proceeds to call
+ *      upstream with an empty credential and returns the IDP's rejection as an
+ *      opaque failure. The user sees recovery "not working", not "not
+ *      authenticated", and the log shows an upstream error rather than an auth
+ *      one. The defect hides itself.
+ *   2. It is BOTH HALVES of account recovery — send-code and verify-code — so
+ *      the entire recovery path is unreachable, not merely degraded. This is
+ *      the flow a locked-out user reaches for, i.e. it fails exactly when it is
+ *      the only thing left that could help them.
+ *
+ * Fixed the same way as profile.ts and masked-info.ts: idpFetchJSON resolves
+ * the caller's token from the server-side session, so the cookie works and the
+ * token is never handed to browser JavaScript.
+ *
+ * @package @payez/next-mvp
+ */
 export declare function POST(req: NextRequest): Promise<NextResponse<any>>;

package/dist/api-handlers/account/recovery/send-code.js

@@ -2,27 +2,61 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.POST = POST;
 const server_1 = require("next/server");
-function getIdpUrl() {
-    const url = process.env.IDP_URL;
-    if (!url)
-        throw new Error('[IDP_URL] FATAL: IDP_URL environment variable is REQUIRED.');
-    return url;
-}
+const idp_fetch_1 = require("../../../lib/idp-fetch");
+const env_1 = require("../../../config/env");
+/**
+ * Account recovery — send-code
+ *
+ * WHY THIS WAS REWRITTEN (2026-08-02, swept out of QAPert defect #7)
+ * This handler read the caller's bearer straight off the inbound request:
+ *
+ *     const auth  = req.headers.get('authorization') || '';
+ *     const token = auth.startsWith('Bearer ') ? auth.slice(7) : '';
+ *     ... headers: { 'Authorization': `Bearer ${token}` }
+ *
+ * Browsers send a session COOKIE and no Authorization header, so `token` was
+ * ALWAYS the empty string and this always called the IDP with a literal
+ * "Bearer " and nothing after it.
+ *
+ * THAT IS WORSE THAN THE profile.ts VERSION OF THIS BUG, in two ways:
+ *
+ *   1. profile.ts at least 401'd when the header was missing. This one has no
+ *      check at all — `|| ''` swallows the absence — so it proceeds to call
+ *      upstream with an empty credential and returns the IDP's rejection as an
+ *      opaque failure. The user sees recovery "not working", not "not
+ *      authenticated", and the log shows an upstream error rather than an auth
+ *      one. The defect hides itself.
+ *   2. It is BOTH HALVES of account recovery — send-code and verify-code — so
+ *      the entire recovery path is unreachable, not merely degraded. This is
+ *      the flow a locked-out user reaches for, i.e. it fails exactly when it is
+ *      the only thing left that could help them.
+ *
+ * Fixed the same way as profile.ts and masked-info.ts: idpFetchJSON resolves
+ * the caller's token from the server-side session, so the cookie works and the
+ * token is never handed to browser JavaScript.
+ *
+ * @package @payez/next-mvp
+ */
 async function POST(req) {
-    const IDP_URL = getIdpUrl();
+    let payload = {};
     try {
-        const auth = req.headers.get('authorization') || '';
-        const token = auth.startsWith('Bearer ') ? auth.slice(7) : '';
-        const { method } = await req.json();
-        const upstream = await fetch(`${IDP_URL}/api/Account/recovery/send-code`, {
-            method: 'POST',
-            headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${token}` },
-            body: JSON.stringify({ method }),
-        });
-        const data = await upstream.json().catch(() => ({}));
-        return server_1.NextResponse.json(data, { status: upstream.status });
+        payload = await req.json();
     }
     catch {
-        return server_1.NextResponse.json({ success: false, error: 'send_code_failed' }, { status: 500 });
+        return server_1.NextResponse.json({ success: false, error: 'invalid_request', message: 'A JSON body is required' }, { status: 400 });
+    }
+    const result = await (0, idp_fetch_1.idpFetchJSON)(req, `${env_1.ENV_CONFIG.IDP_URL}/api/Account/recovery/send-code`, {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(payload),
+    });
+    if (!result.ok) {
+        return server_1.NextResponse.json({
+            success: false,
+            error: 'send_code_failed',
+            message: result.json?.message || 'Upstream error',
+            meta: { status: result.status, attemptedRefresh: result.attemptedRefresh },
+        }, { status: result.status });
     }
+    return server_1.NextResponse.json(result.json, { status: 200 });
 }

package/dist/api-handlers/account/recovery/verify-code.d.ts

@@ -1,2 +1,35 @@
 import { NextRequest, NextResponse } from 'next/server';
+/**
+ * Account recovery — verify-code
+ *
+ * WHY THIS WAS REWRITTEN (2026-08-02, swept out of QAPert defect #7)
+ * This handler read the caller's bearer straight off the inbound request:
+ *
+ *     const auth  = req.headers.get('authorization') || '';
+ *     const token = auth.startsWith('Bearer ') ? auth.slice(7) : '';
+ *     ... headers: { 'Authorization': `Bearer ${token}` }
+ *
+ * Browsers send a session COOKIE and no Authorization header, so `token` was
+ * ALWAYS the empty string and this always called the IDP with a literal
+ * "Bearer " and nothing after it.
+ *
+ * THAT IS WORSE THAN THE profile.ts VERSION OF THIS BUG, in two ways:
+ *
+ *   1. profile.ts at least 401'd when the header was missing. This one has no
+ *      check at all — `|| ''` swallows the absence — so it proceeds to call
+ *      upstream with an empty credential and returns the IDP's rejection as an
+ *      opaque failure. The user sees recovery "not working", not "not
+ *      authenticated", and the log shows an upstream error rather than an auth
+ *      one. The defect hides itself.
+ *   2. It is BOTH HALVES of account recovery — send-code and verify-code — so
+ *      the entire recovery path is unreachable, not merely degraded. This is
+ *      the flow a locked-out user reaches for, i.e. it fails exactly when it is
+ *      the only thing left that could help them.
+ *
+ * Fixed the same way as profile.ts and masked-info.ts: idpFetchJSON resolves
+ * the caller's token from the server-side session, so the cookie works and the
+ * token is never handed to browser JavaScript.
+ *
+ * @package @payez/next-mvp
+ */
 export declare function POST(req: NextRequest): Promise<NextResponse<any>>;

package/dist/api-handlers/account/recovery/verify-code.js

@@ -2,27 +2,61 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.POST = POST;
 const server_1 = require("next/server");
-function getIdpUrl() {
-    const url = process.env.IDP_URL;
-    if (!url)
-        throw new Error('[IDP_URL] FATAL: IDP_URL environment variable is REQUIRED.');
-    return url;
-}
+const idp_fetch_1 = require("../../../lib/idp-fetch");
+const env_1 = require("../../../config/env");
+/**
+ * Account recovery — verify-code
+ *
+ * WHY THIS WAS REWRITTEN (2026-08-02, swept out of QAPert defect #7)
+ * This handler read the caller's bearer straight off the inbound request:
+ *
+ *     const auth  = req.headers.get('authorization') || '';
+ *     const token = auth.startsWith('Bearer ') ? auth.slice(7) : '';
+ *     ... headers: { 'Authorization': `Bearer ${token}` }
+ *
+ * Browsers send a session COOKIE and no Authorization header, so `token` was
+ * ALWAYS the empty string and this always called the IDP with a literal
+ * "Bearer " and nothing after it.
+ *
+ * THAT IS WORSE THAN THE profile.ts VERSION OF THIS BUG, in two ways:
+ *
+ *   1. profile.ts at least 401'd when the header was missing. This one has no
+ *      check at all — `|| ''` swallows the absence — so it proceeds to call
+ *      upstream with an empty credential and returns the IDP's rejection as an
+ *      opaque failure. The user sees recovery "not working", not "not
+ *      authenticated", and the log shows an upstream error rather than an auth
+ *      one. The defect hides itself.
+ *   2. It is BOTH HALVES of account recovery — send-code and verify-code — so
+ *      the entire recovery path is unreachable, not merely degraded. This is
+ *      the flow a locked-out user reaches for, i.e. it fails exactly when it is
+ *      the only thing left that could help them.
+ *
+ * Fixed the same way as profile.ts and masked-info.ts: idpFetchJSON resolves
+ * the caller's token from the server-side session, so the cookie works and the
+ * token is never handed to browser JavaScript.
+ *
+ * @package @payez/next-mvp
+ */
 async function POST(req) {
-    const IDP_URL = getIdpUrl();
+    let payload = {};
     try {
-        const auth = req.headers.get('authorization') || '';
-        const token = auth.startsWith('Bearer ') ? auth.slice(7) : '';
-        const { code, method } = await req.json();
-        const upstream = await fetch(`${IDP_URL}/api/Account/recovery/verify-code`, {
-            method: 'POST',
-            headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${token}` },
-            body: JSON.stringify({ code, method }),
-        });
-        const data = await upstream.json().catch(() => ({}));
-        return server_1.NextResponse.json(data, { status: upstream.status });
+        payload = await req.json();
     }
     catch {
-        return server_1.NextResponse.json({ success: false, error: 'verify_code_failed' }, { status: 500 });
+        return server_1.NextResponse.json({ success: false, error: 'invalid_request', message: 'A JSON body is required' }, { status: 400 });
+    }
+    const result = await (0, idp_fetch_1.idpFetchJSON)(req, `${env_1.ENV_CONFIG.IDP_URL}/api/Account/recovery/verify-code`, {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json' },
+        body: JSON.stringify(payload),
+    });
+    if (!result.ok) {
+        return server_1.NextResponse.json({
+            success: false,
+            error: 'verify_code_failed',
+            message: result.json?.message || 'Upstream error',
+            meta: { status: result.status, attemptedRefresh: result.attemptedRefresh },
+        }, { status: result.status });
     }
+    return server_1.NextResponse.json(result.json, { status: 200 });
 }

package/dist/api-handlers/account/verify-email.js

@@ -44,6 +44,10 @@ async function POST(req) {
         // Unwrap IDP envelope
         const unwrappedData = result.json?.data || result.json;
         // If we have new tokens, update the session to complete 2FA
+        // Reports whether the session ACTUALLY transitioned. Must not be assumed
+        // from a 2xx: the IDP can verify the code while we fail to transition
+        // (no tokens returned, or no resolvable session token).
+        let sessionTransitioned = false;
         if (unwrappedData.access_token && unwrappedData.refresh_token) {
             // Get session token from NextAuth
             // Support both field names: sessionToken (auth.ts JWT) and redisSessionId (legacy)
@@ -81,17 +85,27 @@ async function POST(req) {
                     refreshTokenExpires
                 }, 'email' // Store 2FA method for refresh token flow
                 );
+                sessionTransitioned = true;
                 console.log('[VERIFY_EMAIL] Session updated successfully', {
                     accessTokenExpires: new Date(accessTokenExpires).toISOString(),
                     refreshTokenExpires: new Date(refreshTokenExpires).toISOString()
                 });
             }
+            else {
+                console.warn('[VERIFY_EMAIL] IDP verified the code but no session token was resolvable — session NOT transitioned');
+            }
+        }
+        else {
+            console.warn('[VERIFY_EMAIL] IDP returned 2xx without tokens — session NOT transitioned');
         }
         // Return simplified success response (don't expose tokens to client)
         return server_1.NextResponse.json({
             success: true,
             verificationSuccessful: true,
-            twoFactorSessionVerified: true,
+            // NOT a copy of `success` — reports what actually happened. A client that
+            // trusted a hardcoded true would show the user as MFA-verified while the
+            // session still says otherwise.
+            twoFactorSessionVerified: sessionTransitioned,
             message: unwrappedData.message || 'Email code verified successfully'
         }, { status: 200 });
     }

package/dist/api-handlers/account/verify-sms.js

@@ -44,6 +44,10 @@ async function POST(req) {
         // Unwrap IDP envelope
         const unwrappedData = result.json?.data || result.json;
         // If we have new tokens, update the session to complete 2FA
+        // Reports whether the session ACTUALLY transitioned. Must not be assumed
+        // from a 2xx: the IDP can verify the code while we fail to transition
+        // (no tokens returned, or no resolvable session token).
+        let sessionTransitioned = false;
         if (unwrappedData.access_token && unwrappedData.refresh_token) {
             // Get session token from NextAuth
             // Support both field names: sessionToken (auth.ts JWT) and redisSessionId (legacy)
@@ -81,17 +85,27 @@ async function POST(req) {
                     refreshTokenExpires
                 }, 'sms' // Store 2FA method for refresh token flow
                 );
+                sessionTransitioned = true;
                 console.log('[VERIFY_SMS] Session updated successfully', {
                     accessTokenExpires: new Date(accessTokenExpires).toISOString(),
                     refreshTokenExpires: new Date(refreshTokenExpires).toISOString()
                 });
             }
+            else {
+                console.warn('[VERIFY_SMS] IDP verified the code but no session token was resolvable — session NOT transitioned');
+            }
+        }
+        else {
+            console.warn('[VERIFY_SMS] IDP returned 2xx without tokens — session NOT transitioned');
         }
         // Return simplified success response (don't expose tokens to client)
         return server_1.NextResponse.json({
             success: true,
             verificationSuccessful: true,
-            twoFactorSessionVerified: true,
+            // NOT a copy of `success` — reports what actually happened. A client that
+            // trusted a hardcoded true would show the user as MFA-verified while the
+            // session still says otherwise.
+            twoFactorSessionVerified: sessionTransitioned,
             message: unwrappedData.message || 'SMS code verified successfully'
         }, { status: 200 });
     }

package/dist/api-handlers/auth/passkey-signin.d.ts

@@ -0,0 +1,29 @@
+import { NextRequest, NextResponse } from 'next/server';
+export declare function optionsPOST(req: NextRequest): Promise<NextResponse<any>>;
+/**
+ * VERIFY DOES NOT USE anonCall — IT MUST RESHAPE, NOT SPREAD.
+ *
+ * The IDP contract is three fields (PasskeyModels.cs:36 PasskeyAuthVerifyRequest):
+ *     assertion_id : string
+ *     response     : the WHOLE AuthenticatorAssertionRawResponse from
+ *                    navigator.credentials.get()
+ *     client_id    : string
+ *
+ * anonCall SPREADS the caller's body (`{ client_id, ...parsed }`). For options
+ * that is harmless. For verify it is fatal: spreading an assertion hoists
+ * id/rawId/type to the top level and leaves `response` holding only the INNER
+ * {clientDataJSON, authenticatorData, signature, userHandle}. The IDP's guard
+ * then answers "response is required" in 4-12ms WITHOUT REACHING THE CRYPTO —
+ * a timing signature DotNetPert used to prove the caller was still spreading
+ * long after the graft-side plugin had been fixed.
+ *
+ * This route and the Better Auth plugin endpoint are TWO PATHS to the same IDP
+ * endpoint. Fixing only the plugin left this one live, spreading, and reachable
+ * on a URL one segment away from the correct one — which is what kept the
+ * sign-in leg red across several runs.
+ *
+ * Accepts the assertion either already nested (`{ assertion_id, response }`) or
+ * flat (`{ assertion_id, id, rawId, type, response }`) and normalises both, so a
+ * caller written against either shape works.
+ */
+export declare function verifyPOST(req: NextRequest): Promise<NextResponse<any>>;

package/dist/api-handlers/auth/passkey-signin.js

@@ -0,0 +1,97 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.optionsPOST = optionsPOST;
+exports.verifyPOST = verifyPOST;
+const server_1 = require("next/server");
+const env_1 = require("../../config/env");
+const idp_client_config_1 = require("../../lib/idp-client-config");
+/**
+ * Passkey SIGN-IN ceremony (ANONYMOUS — no session exists yet):
+ *   optionsPOST -> POST /api/ExternalAuth/passwordless/passkey/options
+ *   verifyPOST  -> POST /api/ExternalAuth/passwordless/passkey/verify
+ *
+ * Anon idiom copied from auth/better-auth.ts (exchangeOAuthForIdpTokens):
+ * direct fetch to the IDP, client identified by client_id from the resolved
+ * IDP client config (slug preferred, numeric id fallback) — sent BOTH as the
+ * X-Client-Id header (the probe-verified routing key) and merged into the
+ * body when the caller did not supply one.
+ *
+ * The verify response is passed through WITHOUT unwrapping: this is a
+ * sign-in, its payload carries the grant the caller's session layer consumes.
+ */
+async function clientKey() {
+    const config = await (0, idp_client_config_1.getIDPClientConfig)();
+    return config.clientSlug || String(config.clientId);
+}
+async function anonCall(req, path) {
+    let parsed = {};
+    try {
+        const raw = await req.text();
+        if (raw && raw.trim().length > 0)
+            parsed = JSON.parse(raw);
+    }
+    catch { }
+    const key = await clientKey();
+    const res = await fetch(`${env_1.ENV_CONFIG.IDP_URL}${path}`, {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json', 'X-Client-Id': key },
+        body: JSON.stringify({ client_id: key, ...parsed }),
+        cache: 'no-store',
+    });
+    const json = await res.json().catch(() => null);
+    return { res, json };
+}
+async function optionsPOST(req) {
+    const { res, json } = await anonCall(req, '/api/ExternalAuth/passwordless/passkey/options');
+    return server_1.NextResponse.json(json ?? { success: false, message: 'Empty upstream response' }, { status: res.status });
+}
+/**
+ * VERIFY DOES NOT USE anonCall — IT MUST RESHAPE, NOT SPREAD.
+ *
+ * The IDP contract is three fields (PasskeyModels.cs:36 PasskeyAuthVerifyRequest):
+ *     assertion_id : string
+ *     response     : the WHOLE AuthenticatorAssertionRawResponse from
+ *                    navigator.credentials.get()
+ *     client_id    : string
+ *
+ * anonCall SPREADS the caller's body (`{ client_id, ...parsed }`). For options
+ * that is harmless. For verify it is fatal: spreading an assertion hoists
+ * id/rawId/type to the top level and leaves `response` holding only the INNER
+ * {clientDataJSON, authenticatorData, signature, userHandle}. The IDP's guard
+ * then answers "response is required" in 4-12ms WITHOUT REACHING THE CRYPTO —
+ * a timing signature DotNetPert used to prove the caller was still spreading
+ * long after the graft-side plugin had been fixed.
+ *
+ * This route and the Better Auth plugin endpoint are TWO PATHS to the same IDP
+ * endpoint. Fixing only the plugin left this one live, spreading, and reachable
+ * on a URL one segment away from the correct one — which is what kept the
+ * sign-in leg red across several runs.
+ *
+ * Accepts the assertion either already nested (`{ assertion_id, response }`) or
+ * flat (`{ assertion_id, id, rawId, type, response }`) and normalises both, so a
+ * caller written against either shape works.
+ */
+async function verifyPOST(req) {
+    let parsed = {};
+    try {
+        const raw = await req.text();
+        if (raw && raw.trim().length > 0)
+            parsed = JSON.parse(raw);
+    }
+    catch { /* empty body -> the IDP's own validation answers */ }
+    const { assertion_id: assertionId, response, ...rest } = parsed;
+    // Already-nested callers send `response` holding a full assertion (it has an
+    // `id`). Flat callers send the assertion's own fields alongside assertion_id,
+    // and their `response` is the inner attestation half — not a whole assertion.
+    const nested = response && typeof response === 'object' && 'id' in response;
+    const assertion = nested ? response : { ...rest, response };
+    const key = await clientKey();
+    const res = await fetch(`${env_1.ENV_CONFIG.IDP_URL}/api/ExternalAuth/passwordless/passkey/verify`, {
+        method: 'POST',
+        headers: { 'Content-Type': 'application/json', 'X-Client-Id': key },
+        body: JSON.stringify({ client_id: key, assertion_id: assertionId, response: assertion }),
+        cache: 'no-store',
+    });
+    const json = await res.json().catch(() => null);
+    return server_1.NextResponse.json(json ?? { success: false, message: 'Empty upstream response' }, { status: res.status });
+}