@coreiam/auth 1.0.7 → 1.0.9

package/dist/nextjs/actions.d.ts

@@ -4,7 +4,7 @@ export interface AuthResult {
     status: number;
     data: any;
 }
-export declare const getSession: () => Promise<CoreIAMIdentity | null>;
+export declare function getSession(): Promise<CoreIAMIdentity | null>;
 export declare function loginActionSdk(identifier: string, password: string): Promise<AuthResult>;
 export declare function registerActionSdk(userData: any): Promise<AuthResult>;
 export declare function logoutActionSdk(): Promise<AuthResult>;

package/dist/nextjs/actions.js

@@ -1,25 +1,134 @@
 "use strict";
+// 'use server';
+// import { cache } from 'react';
+// import { cookies, headers } from 'next/headers';
+// import { CoreIAM, CoreIAMIdentity } from '../core';
+// export interface AuthResult {
+//   ok: boolean;
+//   status: number;
+//   data: any;
+// }
+// // FIX: lazy singleton instead of `const iam = new CoreIAM();` at module
+// // scope. The constructor throws if COREIAM_API_KEY/COREIAM_API_URL are
+// // missing — fine on the server, where those env vars exist — but a
+// // module-level throw happens the instant the module is evaluated, before
+// // any function in it is even called. If this module's 'use server'
+// // boundary is ever not recognized correctly by the bundler (see the note
+// // on the browser error below), the real module gets included in the client
+// // bundle instead of being swapped for action-reference stubs, and that
+// // throw fires in the browser instead, where those env vars are never
+// // defined. Making this lazy doesn't fix a lost 'use server' boundary by
+// // itself, but it does mean import alone can never crash — only an actual
+// // invocation can, which is strictly better either way.
+// let _iam: CoreIAM | null = null;
+// function getIam(): CoreIAM {
+//   if (!_iam) _iam = new CoreIAM();
+//   return _iam;
+// }
+// async function syncCookiesToNext(response: Response) {
+//   const cookieStore = await cookies();
+//   const setCookies = response.headers.getSetCookie();
+//   for (const cookieStr of setCookies) {
+//     const parts = cookieStr.split(';');
+//     const [nameValue, ...attributes] = parts;
+//     const [name, ...valueParts] = nameValue.split('=');
+//     const cookieOptions: any = {};
+//     let isDeleting = false;
+//     attributes.forEach(attr => {
+//       const [attrName, attrValue] = attr.trim().split('=');
+//       const lowerName = attrName?.toLowerCase();
+//       if (lowerName === 'httponly') cookieOptions.httpOnly = true;
+//       if (lowerName === 'secure') cookieOptions.secure = true;
+//       if (lowerName === 'path') cookieOptions.path = attrValue || '/';
+//       if (lowerName === 'max-age') {
+//         const maxAge = parseInt(attrValue, 10);
+//         if (maxAge <= 0) isDeleting = true;
+//         else cookieOptions.maxAge = maxAge;
+//       }
+//       if (lowerName === 'expires') {
+//         const expiryDate = new Date(attrValue);
+//         if (expiryDate.getTime() < Date.now()) isDeleting = true;
+//         else cookieOptions.expires = expiryDate;
+//       }
+//       if (lowerName === 'samesite') cookieOptions.sameSite = attrValue?.toLowerCase() || 'lax';
+//     });
+//     const cookieName = name.trim();
+//     const cookieValue = valueParts.join('=').trim();
+//     if (isDeleting || cookieValue === '') {
+//       cookieStore.delete(cookieName);
+//     } else {
+//       cookieStore.set(cookieName, cookieValue, cookieOptions);
+//     }
+//   }
+// }
+// // FIX: wrapped in React's cache(). This is the generic fix for "why are we
+// // calling /profile so much" — any number of calls to getSession() within the
+// // same request/render (direct calls, or nested inside a consumer's own
+// // currentUser()-style wrapper) now collapse into a single network round trip
+// // to CoreIAM automatically, for every current and future call site.
+// //
+// // Deliberately NOT adding a refresh-retry fallback here (an earlier draft in
+// // this thread did). Next.js only allows cookies().set()/cookies().delete()
+// // inside a Server Action or Route Handler — never during a Server Component
+// // render — and getSession() is called from both (e.g. from a plain
+// // RootLayout render, and from consumers' currentUser()-style wrappers used
+// // throughout Server Components). A refresh path that can only sometimes
+// // persist its new cookies isn't safe: on the render-context call it would
+// // still redeem the refresh token server-side (rotating/burning it) but never
+// // deliver the new one to the browser, stranding the client on a now-dead
+// // refresh token. Refresh belongs solely in middleware.ts, which is the one
+// // place in the request lifecycle actually allowed to mutate response
+// // cookies. If middleware already refreshed upstream, this succeeds; if
+// // middleware's refresh also failed, returning null here is correct, not a
+// // bug to work around.
+// export const getSession = cache(async (): Promise<CoreIAMIdentity | null> => {
+//   const reqHeaders = await headers();
+//   const response = await getIam().proxy('/auth/profile', { method: 'GET' }, reqHeaders);
+//   if (!response.ok) return null;
+//   const coreIamIdentity = await response.json();
+//   if (!coreIamIdentity?.sub) return null;
+//   return coreIamIdentity as CoreIAMIdentity; 
+// });
+// export async function loginActionSdk(identifier: string, password: string): Promise<AuthResult> {
+//   const reqHeaders = await headers();
+//   try {
+//     const response = await getIam().loginWithCsrfProtection(identifier, password, reqHeaders);
+//     await syncCookiesToNext(response);
+//     return { ok: response.ok, status: response.status, data: await response.json().catch(() => ({})) };
+//   } catch (error) {
+//     return { ok: false, status: 500, data: { error: error instanceof Error ? error.message : 'Login failed' } };
+//   }
+// }
+// export async function registerActionSdk(userData: any): Promise<AuthResult> {
+//   const reqHeaders = await headers();
+//   try {
+//     const response = await getIam().registerWithCsrfProtection(userData, reqHeaders);
+//     await syncCookiesToNext(response);
+//     return { ok: response.ok, status: response.status, data: await response.json().catch(() => ({})) };
+//   } catch (error) {
+//     return { ok: false, status: 500, data: { error: error instanceof Error ? error.message : 'Registration failed' } };
+//   }
+// }
+// export async function logoutActionSdk(): Promise<AuthResult> {
+//   const reqHeaders = await headers();
+//   try {
+//     const response = await getIam().logout(reqHeaders);
+//     await syncCookiesToNext(response);
+//     return { ok: response.ok, status: response.status, data: await response.json().catch(() => ({})) };
+//   } catch (error) {
+//     return { ok: false, status: 500, data: { error: 'Logout failed' } };
+//   }
+// }
+// src/nextjs/actions.ts
 'use server';
+// 'use server';
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.getSession = void 0;
+exports.getSession = getSession;
 exports.loginActionSdk = loginActionSdk;
 exports.registerActionSdk = registerActionSdk;
 exports.logoutActionSdk = logoutActionSdk;
-const react_1 = require("react");
 const headers_1 = require("next/headers");
 const core_1 = require("../core");
-// FIX: lazy singleton instead of `const iam = new CoreIAM();` at module
-// scope. The constructor throws if COREIAM_API_KEY/COREIAM_API_URL are
-// missing — fine on the server, where those env vars exist — but a
-// module-level throw happens the instant the module is evaluated, before
-// any function in it is even called. If this module's 'use server'
-// boundary is ever not recognized correctly by the bundler (see the note
-// on the browser error below), the real module gets included in the client
-// bundle instead of being swapped for action-reference stubs, and that
-// throw fires in the browser instead, where those env vars are never
-// defined. Making this lazy doesn't fix a lost 'use server' boundary by
-// itself, but it does mean import alone can never crash — only an actual
-// invocation can, which is strictly better either way.
 let _iam = null;
 function getIam() {
     if (!_iam)
@@ -71,27 +180,9 @@ async function syncCookiesToNext(response) {
         }
     }
 }
-// FIX: wrapped in React's cache(). This is the generic fix for "why are we
-// calling /profile so much" — any number of calls to getSession() within the
-// same request/render (direct calls, or nested inside a consumer's own
-// currentUser()-style wrapper) now collapse into a single network round trip
-// to CoreIAM automatically, for every current and future call site.
-//
-// Deliberately NOT adding a refresh-retry fallback here (an earlier draft in
-// this thread did). Next.js only allows cookies().set()/cookies().delete()
-// inside a Server Action or Route Handler — never during a Server Component
-// render — and getSession() is called from both (e.g. from a plain
-// RootLayout render, and from consumers' currentUser()-style wrappers used
-// throughout Server Components). A refresh path that can only sometimes
-// persist its new cookies isn't safe: on the render-context call it would
-// still redeem the refresh token server-side (rotating/burning it) but never
-// deliver the new one to the browser, stranding the client on a now-dead
-// refresh token. Refresh belongs solely in middleware.ts, which is the one
-// place in the request lifecycle actually allowed to mutate response
-// cookies. If middleware already refreshed upstream, this succeeds; if
-// middleware's refresh also failed, returning null here is correct, not a
-// bug to work around.
-exports.getSession = (0, react_1.cache)(async () => {
+// FIX: MUST be `export async function`, NOT `export const`. 
+// If it's a const, Next.js ignores 'use server' and bundles this file in the client!
+async function getSession() {
     const reqHeaders = await (0, headers_1.headers)();
     const response = await getIam().proxy('/auth/profile', { method: 'GET' }, reqHeaders);
     if (!response.ok)
@@ -100,7 +191,7 @@ exports.getSession = (0, react_1.cache)(async () => {
     if (!coreIamIdentity?.sub)
         return null;
     return coreIamIdentity;
-});
+}
 async function loginActionSdk(identifier, password) {
     const reqHeaders = await (0, headers_1.headers)();
     try {

package/dist/nextjs/index.js

@@ -10,7 +10,6 @@ Object.defineProperty(exports, "loginActionSdk", { enumerable: true, get: functi
 Object.defineProperty(exports, "registerActionSdk", { enumerable: true, get: function () { return actions_1.registerActionSdk; } });
 Object.defineProperty(exports, "logoutActionSdk", { enumerable: true, get: function () { return actions_1.logoutActionSdk; } });
 Object.defineProperty(exports, "getSession", { enumerable: true, get: function () { return actions_1.getSession; } });
-// FIX: Export the new handleCoreIamAuth function instead of the old middleware
 var middleware_1 = require("./middleware");
 Object.defineProperty(exports, "coreIamMiddleware", { enumerable: true, get: function () { return middleware_1.coreIamMiddleware; } });
 const server_1 = require("next/server");
@@ -18,7 +17,6 @@ const core_1 = require("../core");
 class NextHandlers {
     iam;
     constructor(iam) {
-        // If no iam client is provided, instantiate one using the env variables
         this.iam = iam || new core_1.CoreIAM({ apiKey: process.env.COREIAM_API_KEY, baseUrl: process.env.COREIAM_API_URL });
     }
     async handleProxy(req, internalPath) {

package/dist/nextjs/middleware.js

@@ -4,24 +4,6 @@ exports.coreIamMiddleware = coreIamMiddleware;
 // src/nextjs/middleware.ts
 const server_1 = require("next/server");
 const jwt_decode_1 = require("jwt-decode");
-// Module-level: persists across requests as long as this runs in a single,
-// long-running Node process (true for a VPS deploy). This lets concurrent
-// middleware invocations on THIS process share one in-flight refresh
-// instead of each independently redeeming the same (single-use) refresh
-// token and knocking each other out with 401 Invalid refresh token.
-//
-// This lock is per-process by nature — no amount of cleverness here makes
-// it coordinate across multiple Node processes/instances, since it's just
-// in-memory state. That's fine: it's an optimization (avoids the latency
-// and CoreIAM load of firing off N calls that are mostly doomed to fail
-// anyway), not the thing that makes rotation actually correct under
-// concurrency. That guarantee now lives where all callers ultimately
-// converge regardless of how many Qalam or CoreIAM processes exist: a
-// conditional (WHERE isRevoked: false) update inside a transaction in
-// auth.service.ts's refreshToken(), enforced by Postgres itself. If this
-// lock is ever bypassed or scaled beyond one process, refreshes just get a
-// little less efficient (a few requests eagerly hit CoreIAM instead of
-// waiting on a local promise) — they don't get less correct.
 let refreshInFlight = null;
 async function performRefresh(refreshTokenCookie, jwtCookie, gatewayUrl) {
     try {
@@ -92,21 +74,18 @@ async function coreIamMiddleware(request) {
             const response = server_1.NextResponse.next({
                 request: { headers: requestHeaders },
             });
-            // FIX: flags now match cookie.util.ts exactly (httpOnly, sameSite:
-            // 'strict', secure in production only, correct maxAge per cookie),
-            // instead of the placeholder flags used before that file was reviewed.
             const isProd = process.env.NODE_ENV === 'production';
             response.cookies.set('jwt', result.jwt, {
                 httpOnly: true,
                 secure: isProd,
                 sameSite: 'strict',
-                maxAge: 24 * 60 * 60, // seconds — matches the 24h maxAge in cookie.util.ts
+                maxAge: 24 * 60 * 60,
             });
             response.cookies.set('refreshToken', result.refreshToken, {
                 httpOnly: true,
                 secure: isProd,
                 sameSite: 'strict',
-                maxAge: 7 * 24 * 60 * 60, // seconds — matches the 7d maxAge in cookie.util.ts
+                maxAge: 7 * 24 * 60 * 60,
             });
             return { response, isAuthenticated: true };
         }

package/dist/nextjs/provider.js

@@ -16,9 +16,9 @@ const AuthContext = (0, react_1.createContext)({
     register: async () => ({ error: 'CoreIAMProvider is not mounted' }),
     refetchIdentity: async () => { },
 });
-function CoreIAMProvider({ children, initialIdentity = null, redirects = {}, }) {
-    const [identity, setIdentity] = (0, react_1.useState)(initialIdentity);
-    const [isLoading, setIsLoading] = (0, react_1.useState)(initialIdentity === null);
+function CoreIAMProvider({ children, initialIdentity, redirects = {}, }) {
+    const [identity, setIdentity] = (0, react_1.useState)(initialIdentity ?? null);
+    const [isLoading, setIsLoading] = (0, react_1.useState)(initialIdentity === undefined);
     const router = (0, navigation_1.useRouter)();
     const refetchIdentity = async () => {
         try {
@@ -33,7 +33,16 @@ function CoreIAMProvider({ children, initialIdentity = null, redirects = {}, })
         }
     };
     (0, react_1.useEffect)(() => {
-        if (initialIdentity === null) {
+        // FIX: was `initialIdentity === null`, which can't tell "SSR ran and
+        // confirmed you're logged out" (a correct, final null) apart from "no
+        // SSR value was ever provided" (a real undefined). Since layout.tsx
+        // always calls getSession() and passes its result — even when that
+        // result legitimately is null — every logged-out page view was
+        // treated as "no SSR value, fetch again," firing a second, wholly
+        // redundant /auth/profile call for something SSR had already
+        // determined. undefined (the prop genuinely omitted) is the only case
+        // that should trigger this fallback fetch.
+        if (initialIdentity === undefined) {
             refetchIdentity();
         }
         else {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@coreiam/auth",
-  "version": "1.0.7",
+  "version": "1.0.9",
   "main": "./dist/core/index.js",
   "types": "./dist/core/index.d.ts",
   "exports": {