@seliseblocks/cli-os 0.2.4 → 0.2.6

package/dist/commands/auth/config/save.js

@@ -7,7 +7,7 @@ import { requestContext } from "../../../lib/request-context.js";
 import { parseCommand, selectedProject } from "../../../lib/workspace.js";
 export async function authConfigSave(argv) {
     const { flags } = parseCommand(argv);
-    const body = {
+    const overrides = {
         ...(await jsonBodyFlag(flags)),
         ...compact({
             absoluteRefreshTokenValidForNumberMinutes: optionalIntegerFlag(flags, "absolute-refresh-token-minutes"),
@@ -21,12 +21,22 @@ export async function authConfigSave(argv) {
             rememberMeRefreshTokenValidForNumberMinutes: optionalIntegerFlag(flags, "remember-me-refresh-token-minutes")
         })
     };
+    const projectKey = await selectedProject(flags);
+    // POST /auth/config replaces the whole config document rather than merging
+    // (confirmed against the portal's own save call, which always resends every
+    // field it read on load) -- fetch the current config first so fields the
+    // caller didn't mention here survive the round trip instead of resetting.
+    const current = await blocksRequest("/iam/v4/auth/config", {
+        impersonatedProjectAuth: true,
+        ...requestContext(flags),
+        projectTenantId: projectKey
+    });
+    const body = { ...current, ...overrides };
     if (booleanFlag(flags, "dry-run")) {
         writeOutput({ dryRun: true, endpoint: "/iam/v4/auth/config", request: body }, flags);
         return;
     }
     await confirmMutation(flags, "Save AuthController configuration for the selected project.");
-    const projectKey = await selectedProject(flags);
     const result = await blocksRequest("/iam/v4/auth/config", {
         body,
         impersonatedProjectAuth: true,

package/dist/commands/auth/oidc-clients/save.js

@@ -8,7 +8,7 @@ import { parseCommand, selectedProject } from "../../../lib/workspace.js";
 /** Upsert: omit --item-id to register a new OIDC client, pass it to update an existing one. */
 export async function authOidcClientsSave(argv) {
     const { flags } = parseCommand(argv);
-    const body = {
+    const overrides = {
         ...(await jsonBodyFlag(flags)),
         ...compact({
             allowedMfaMethods: listFlag(flags, "allowed-mfa-methods")?.map(Number),
@@ -36,12 +36,27 @@ export async function authOidcClientsSave(argv) {
             useTokensCookie: optionalBooleanFlag(flags, "use-tokens-cookie")
         })
     };
+    const projectKey = await selectedProject(flags);
+    const itemId = typeof overrides.itemId === "string" ? overrides.itemId : undefined;
+    // Saving an existing client (itemId set) replaces the whole client document
+    // rather than merging -- the portal's own Edit dialog always resubmits every
+    // field, including ones this command wasn't asked to change. Fetch the
+    // current client first so unmentioned fields (redirectUris, scope, PKCE, ...)
+    // survive instead of being reset to defaults. A new client (no itemId) has
+    // no prior state to merge.
+    const current = itemId
+        ? await blocksRequest(`/iam/v4/oidc-clients/${encodeURIComponent(itemId)}`, {
+            impersonatedProjectAuth: true,
+            ...requestContext(flags),
+            projectTenantId: projectKey
+        })
+        : {};
+    const body = { ...current, ...overrides };
     if (booleanFlag(flags, "dry-run")) {
         writeOutput({ dryRun: true, endpoint: "/iam/v4/oidc-clients", request: redactSecret(body) }, flags);
         return;
     }
     await confirmMutation(flags, `Save OIDC client '${body.clientDisplayName ?? body.itemId ?? "(new)"}'. The response's client secret is shown once.`);
-    const projectKey = await selectedProject(flags);
     const result = await blocksRequest("/iam/v4/oidc-clients", {
         body,
         impersonatedProjectAuth: true,

package/dist/commands/new/web.js

@@ -21,6 +21,15 @@ export async function newWeb(argv) {
     const appDomain = await resolveAppDomain(project, flags);
     const apiUrl = stringFlag(flags, "blocks-api-url") || apiUrlFromAppDomain(appDomain);
     const oidcClientId = await resolveOidcClientId(tenantId, appDomain, name, flags);
+    if (oidcClientId) {
+        try {
+            await ensureOidcLoginEnabled(tenantId, flags);
+        }
+        catch (error) {
+            console.warn(`Warning: could not confirm/enable OIDC login on this project's AuthController config: ${error.message}`);
+            console.warn("Enable it manually: 'blocks auth:config:save --oidc-enabled --project " + tenantId + "', or in the Blocks portal under IAM > Auth Config.");
+        }
+    }
     await scaffoldWebProject({
         apiUrl,
         appDomain,
@@ -116,6 +125,32 @@ async function listOidcClientSummaries(tenantId, flags) {
     }
     return summaries;
 }
+// Creating/selecting an OIDC client is not enough for the hosted login flow to
+// work: AuthController separately gates the whole OIDC/IdP path behind
+// isOidcEnabled on the tenant's auth config, off by default. Without this,
+// scaffolded apps 404/error on login until someone flips it manually in the
+// portal (IAM > Auth Config), so check-and-enable it here as part of setup.
+// POST /auth/config replaces the whole config document rather than merging
+// (confirmed against the portal's own save call, which always resends every
+// field) -- sending just `{ isOidcEnabled: true }` would reset every other
+// AuthController setting for this tenant, so the fetched config is spread
+// back in full with only that one field overridden.
+async function ensureOidcLoginEnabled(tenantId, flags) {
+    const config = await blocksRequest("/iam/v4/auth/config", {
+        impersonatedProjectAuth: true,
+        projectTenantId: tenantId,
+        ...requestContext(flags)
+    });
+    if (config.isOidcEnabled)
+        return;
+    await confirmMutation(flags, "Enable OIDC login on this project's AuthController configuration.");
+    await blocksRequest("/iam/v4/auth/config", {
+        body: { ...config, isOidcEnabled: true },
+        impersonatedProjectAuth: true,
+        projectTenantId: tenantId,
+        ...requestContext(flags)
+    });
+}
 function normalizeList(raw) {
     if (Array.isArray(raw))
         return raw;
@@ -135,10 +170,15 @@ async function createOidcClientInteractively(tenantId, appDomain, appName, flags
     // clientType drives IAM's tokenEndpointAuthMethod: omitting it stores this browser
     // app as confidential ("client_secret_post") and lets it request client_credentials.
     // The scaffold only ever produces a PKCE SPA, so it is always "public".
+    // isAutoRedirect: the scaffolded login page's startLogin() already navigates
+    // straight to the provider via window.location.assign -- without this flag IAM
+    // shows an interstitial "continue" click on the hosted login page instead of
+    // redirecting immediately, which is dead weight for a flow the SPA already drives.
     const body = {
         clientDisplayName: displayName,
         clientType: "public",
         isActive: true,
+        isAutoRedirect: true,
         redirectUris: [redirectUri],
         registerAsIdentityProvider: true,
         requirePkce: true,

package/dist/lib/scaffold-web/app-core.js

@@ -80,7 +80,7 @@ export async function writeAppCore(root) {
     await write(root, "src/app/providers/AuthProvider.tsx", [
         "import { createContext, useCallback, useContext, useEffect, useMemo, useState } from \"react\";",
         "import type { ReactNode } from \"react\";",
-        "import { fetchSessionClaims, logout as endSession, startLogin } from \"../../lib/blocks/auth\";",
+        "import { fetchSessionClaims, logout as endSession, onSessionExpired, startLogin } from \"../../lib/blocks/auth\";",
         "",
         "type AuthStatus = \"authenticated\" | \"loading\" | \"unauthenticated\";",
         "",
@@ -129,6 +129,11 @@ export async function writeAppCore(root) {
         "    };",
         "  }, [refresh]);",
         "",
+        "  // Fires when a reactive 401 forced a refresh and IAM rejected the refresh",
+        "  // token outright (invalid_grant) -- blocks/auth.ts already ended the",
+        "  // session server-side, this just gets the UI to notice and redirect.",
+        "  useEffect(() => onSessionExpired(() => void refresh()), [refresh]);",
+        "",
         "  const login = useCallback(async (returnTo?: string) => {",
         "    await startLogin(returnTo);",
         "  }, []);",

package/dist/lib/scaffold-web/blocks-lib.js

@@ -54,17 +54,22 @@ export async function writeBlocksLib(root) {
     await write(root, "src/lib/blocks/client.ts", [
         "import { createBlocksClient } from \"@seliseblocks/client\";",
         "import { blocksConfig } from \"./config\";",
-        "import { getValidAccessToken } from \"./auth\";",
+        "import { forceRefreshAccessToken, getValidAccessToken } from \"./auth\";",
         "",
         "// Single Blocks API entry point for this app -- every Auth, IAM, Data, and",
         "// Localization call goes through this client, never a hand-written fetch().",
         "// `accessToken` is a caller-owned resolver: the SDK reads it before each",
         "// protected call but never stores/refreshes/clears it itself, so the actual",
         "// session lifecycle (storage, refresh-before-expiry) lives in ./auth.ts.",
+        "// `onUnauthorized` is the reactive counterpart: it only fires when a call",
+        "// comes back 401 despite a locally-valid-looking token (server-side",
+        "// revocation, clock skew), and shares the same in-flight refresh as the",
+        "// proactive path so concurrent 401s resolve one refresh, not one each.",
         "export const blocksClient = createBlocksClient({",
         "  accessToken: () => getValidAccessToken(),",
         "  apiUrl: blocksConfig.apiUrl,",
         "  appDomain: blocksConfig.appDomain,",
+        "  onUnauthorized: () => forceRefreshAccessToken(),",
         "  oidc: {",
         "    clientId: blocksConfig.oidcClientId,",
         "    scope: blocksConfig.oidcScope,",
@@ -94,6 +99,21 @@ export async function writeBlocksLib(root) {
         "let cachedRefreshToken: string | undefined;",
         "let refreshInFlight: Promise<string | undefined> | undefined;",
         "",
+        "// AuthProvider subscribes to this to learn the session died out-of-band (a",
+        "// refresh came back invalid_grant) so it can flip status to unauthenticated",
+        "// and let RequireAuth redirect to /login -- this module has no router access",
+        "// of its own to do that navigation directly.",
+        "const sessionExpiredListeners = new Set<() => void>();",
+        "",
+        "export function onSessionExpired(listener: () => void): () => void {",
+        "  sessionExpiredListeners.add(listener);",
+        "  return () => sessionExpiredListeners.delete(listener);",
+        "}",
+        "",
+        "function notifySessionExpired(): void {",
+        "  for (const listener of sessionExpiredListeners) listener();",
+        "}",
+        "",
         "function getAccessToken(): string | undefined {",
         "  if (cachedAccessToken && !isJwtExpired(cachedAccessToken)) return cachedAccessToken;",
         "",
@@ -137,7 +157,17 @@ export async function writeBlocksLib(root) {
         "export async function getValidAccessToken(): Promise<string | undefined> {",
         "  const current = getAccessToken();",
         "  if (current) return current;",
+        "  return forceRefreshAccessToken();",
+        "}",
         "",
+        "// Passed to createBlocksClient as `onUnauthorized`: unlike getValidAccessToken,",
+        "// this skips the \"is the cached token still fresh\" check and always goes",
+        "// straight to refreshAccessToken() -- a 401 means the server already",
+        "// disagreed with our local judgment of freshness, so re-checking it would",
+        "// just resend the same rejected token. Still funnels through the same",
+        "// refreshInFlight guard, so a burst of concurrent 401s (and any proactive",
+        "// caller racing them) share one refresh call instead of firing one each.",
+        "export async function forceRefreshAccessToken(): Promise<string | undefined> {",
         "  const refreshToken = getRefreshToken();",
         "  if (!refreshToken) return undefined;",
         "",
@@ -166,8 +196,12 @@ export async function writeBlocksLib(root) {
         "  if (!accessToken) {",
         "    // IAM answered but explicitly rejected the grant (e.g. invalid_grant --",
         "    // the refresh token expired or was already rotated away) -- now it",
-        "    // really is dead, so there is nothing left to retry with.",
+        "    // really is dead, so this is a full sign-out, not just a cache clear.",
+        "    // Clear local state before the logout call so its own accessToken",
+        "    // lookup finds nothing to refresh and doesn't loop back into us.",
         "    clearLocalTokens();",
+        "    await blocksClient.auth.logout({ refreshToken }).catch(() => undefined);",
+        "    notifySessionExpired();",
         "    return undefined;",
         "  }",
         "",

package/dist/skills/blocks-iam-access-control/SKILL.md

@@ -1,49 +1,49 @@
----
-name: blocks-iam-access-control
-description: "Work with SELISE Blocks RBAC (roles & permissions) via `blocks iam roles/permissions *` (CLI, project-scoped) or `blocksClient.iam.*` (SDK), never raw fetch/curl. Two facets: read-only feature-gating by the current user's own roles/permissions (common, safe) vs. creating/editing role and permission definitions (sensitive, human-confirmed only — CLI `--dry-run`→`--yes` or an in-app admin screen). OIDC/identity-provider provisioning stays portal-only, a different concern. Use for permission-gated UI, role/permission pickers, or building/scripting role & permission admin ('gate this button by permission', 'create a role and grant permissions', 'list permissions by severity')."
----
-
-# Blocks IAM — Access Control (Permissions & Roles)
-
-This skill covers **permission and role definitions** in SELISE Blocks — the RBAC model itself, not who has which role (that's the blocks-iam-users skill). Everything goes through either `blocks iam roles/permissions *` (CLI) or `blocksClient.iam.*` from **`@seliseblocks/client`**, the single SDK instance every `blocks new web` scaffold wires up at `src/lib/blocks/client.ts` and exports as `blocksClient`. No raw `fetch`/`curl` for either surface.
-
-```ts
-import { blocksClient } from "../../lib/blocks/client";
-```
-
-## The platform boundary — read this before writing any code
-
-Role and permission administration is **not** portal-only or app-UI-only — `blocks` has a full, working CLI surface for it too. There are two equally real surfaces for the same operations, and the choice is about *where the human is*, not which one is "allowed" — see [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md) for the full command reference and the CLI-vs-SDK decision.
-
-Identity-provider/OIDC client provisioning is the one piece that really is **portal-only, human-driven**, at `https://os.seliseblocks.com` — unrelated to roles/permissions, don't bolt it onto this skill.
-
-Keep the two facets below (read-only feature-gating vs. sensitive admin mutations) separate in your head (and in your code) — they have very different risk profiles regardless of which surface (CLI or SDK) you're using.
-
-## Facet 1 — Feature-gating a frontend by the user's own permissions (common, low risk)
-
-Read-only, scoped to whoever is signed in, needs no special confirmation. `useCurrentUser()` + `iam.resources.features()` + `iam.roles.assignable()`.
-
-→ Full walkthrough: [flows/feature-gating.md](flows/feature-gating.md)
-
-## Facet 2 — Creating/editing roles & permissions (sensitive)
-
-Legitimate only in direct response to a human's explicit, in-the-moment instruction — CLI (`--dry-run` reviewed, then `--yes`) or a signed-in admin's own in-app screen. Never something an agent decides to invoke on its own initiative.
-
-→ Full command reference, SDK methods, and confirm-before-mutating pattern: [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md)
-
-## Gotchas
-
-- **CLI mutations are project-scoped, not account-scoped** — they run against the impersonated-project token; `blocks iam me` is the one IAM command that uses the account token instead.
-- **Role hierarchy and permission assignment key off `slug`**, not `itemId`.
-- **Never fire a create/update/assign-permissions call — CLI or SDK — without a human confirming that specific change first.** See [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md) for the full discipline.
-- **OIDC/identity-provider client provisioning is always portal-only**, independent of everything above.
-
-## Example trigger prompts
-
-- "Only show the delete button to users who have the `order::delete` permission." → Facet 1
-- "Hide this whole admin section unless the signed-in user has an admin role." → Facet 1
-- "What roles am I allowed to assign to other users?" → Facet 1
-- "Show me permissions grouped by severity in a settings panel." → Facet 1
-- "Build an admin page where I can create a role and pick which permissions it gets." → Facet 2
-- "Create a `content-editor` role from the CLI with these permissions." → Facet 2
-- "Can you just set up a few default roles for my project?" → confirm the exact list with the human first (in chat, or via a reviewed `--dry-run`), then run each `blocks iam roles create`/`assign-permissions` with `--yes` only after they say go — don't auto-provision without that per-change confirmation.
+---
+name: blocks-iam-access-control
+description: "Work with SELISE Blocks RBAC (roles & permissions) via `blocks iam roles/permissions *` (CLI, project-scoped) or `blocksClient.iam.*` (SDK), never raw fetch/curl. Two facets: read-only feature-gating by the current user's own roles/permissions (common, safe) vs. creating/editing role and permission definitions (sensitive, human-confirmed only — CLI `--dry-run`→`--yes` or an in-app admin screen). OIDC/identity-provider provisioning stays portal-only, a different concern. Use for permission-gated UI, role/permission pickers, or building/scripting role & permission admin ('gate this button by permission', 'create a role and grant permissions', 'list permissions by severity')."
+---
+
+# Blocks IAM — Access Control (Permissions & Roles)
+
+This skill covers **permission and role definitions** in SELISE Blocks — the RBAC model itself, not who has which role (that's the blocks-iam-users skill). Everything goes through either `blocks iam roles/permissions *` (CLI) or `blocksClient.iam.*` from **`@seliseblocks/client`**, the single SDK instance every `blocks new web` scaffold wires up at `src/lib/blocks/client.ts` and exports as `blocksClient`. No raw `fetch`/`curl` for either surface.
+
+```ts
+import { blocksClient } from "../../lib/blocks/client";
+```
+
+## The platform boundary — read this before writing any code
+
+Role and permission administration is **not** portal-only or app-UI-only — `blocks` has a full, working CLI surface for it too. There are two equally real surfaces for the same operations, and the choice is about *where the human is*, not which one is "allowed" — see [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md) for the full command reference and the CLI-vs-SDK decision.
+
+Identity-provider/OIDC client provisioning is the one piece that really is **portal-only, human-driven**, at `https://os.seliseblocks.com` — unrelated to roles/permissions, don't bolt it onto this skill.
+
+Keep the two facets below (read-only feature-gating vs. sensitive admin mutations) separate in your head (and in your code) — they have very different risk profiles regardless of which surface (CLI or SDK) you're using.
+
+## Facet 1 — Feature-gating a frontend by the user's own permissions (common, low risk)
+
+Read-only, scoped to whoever is signed in, needs no special confirmation. `useCurrentUser()` + `iam.resources.features()` + `iam.roles.assignable()`.
+
+→ Full walkthrough: [flows/feature-gating.md](flows/feature-gating.md)
+
+## Facet 2 — Creating/editing roles & permissions (sensitive)
+
+Legitimate only in direct response to a human's explicit, in-the-moment instruction — CLI (`--dry-run` reviewed, then `--yes`) or a signed-in admin's own in-app screen. Never something an agent decides to invoke on its own initiative.
+
+→ Full command reference, SDK methods, and confirm-before-mutating pattern: [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md)
+
+## Gotchas
+
+- **CLI mutations are project-scoped, not account-scoped** — they run against the impersonated-project token; `blocks iam me` is the one IAM command that uses the account token instead.
+- **Role hierarchy and permission assignment key off `slug`**, not `itemId`.
+- **Never fire a create/update/assign-permissions call — CLI or SDK — without a human confirming that specific change first.** See [flows/manage-roles-permissions.md](flows/manage-roles-permissions.md) for the full discipline.
+- **OIDC/identity-provider client provisioning is always portal-only**, independent of everything above.
+
+## Example trigger prompts
+
+- "Only show the delete button to users who have the `order::delete` permission." → Facet 1
+- "Hide this whole admin section unless the signed-in user has an admin role." → Facet 1
+- "What roles am I allowed to assign to other users?" → Facet 1
+- "Show me permissions grouped by severity in a settings panel." → Facet 1
+- "Build an admin page where I can create a role and pick which permissions it gets." → Facet 2
+- "Create a `content-editor` role from the CLI with these permissions." → Facet 2
+- "Can you just set up a few default roles for my project?" → confirm the exact list with the human first (in chat, or via a reviewed `--dry-run`), then run each `blocks iam roles create`/`assign-permissions` with `--yes` only after they say go — don't auto-provision without that per-change confirmation.

package/dist/skills/blocks-iam-access-control/flows/feature-gating.md

@@ -1,38 +1,38 @@
-# Flow: Feature-gating a frontend by the user's own permissions (common, low risk)
-
-This is read-only against IAM and scoped to whoever is signed in, so it needs no special confirmation — build it the same way you'd build any other data-fetching feature.
-
-The scaffold already gives you a `useCurrentUser()` hook (`src/features/profile/useCurrentUser.ts`) wrapping `blocksClient.iam.me()` with TanStack Query; `me()` returns `{ data: { itemId, email, firstName, lastName, roles: string[], permissions: string[], ... } }`. Reuse it instead of re-fetching:
-
-```ts
-// src/features/access/usePermission.ts
-import { useCurrentUser } from "../profile/useCurrentUser";
-
-export function useHasPermission(permission: string): boolean {
-  const me = useCurrentUser();
-  return me.data?.data?.permissions?.includes(permission) ?? false;
-}
-
-export function useHasRole(role: string): boolean {
-  const me = useCurrentUser();
-  return me.data?.data?.roles?.includes(role) ?? false;
-}
-```
-
-```tsx
-// src/shared/ui/RequirePermission.tsx
-import type { ReactNode } from "react";
-import { useHasPermission } from "../../features/access/usePermission";
-
-export function RequirePermission({ permission, children }: { permission: string; children: ReactNode }) {
-  if (!useHasPermission(permission)) return null;
-  return <>{children}</>;
-}
-```
-
-Two more read methods round this out:
-
-- `blocksClient.iam.resources.features(query?)` — feature/resource flags for the active user context; use this to drive nav items or feature flags that are more granular than a flat permission string.
-- `blocksClient.iam.roles.assignable()` — lists roles the **current caller** is allowed to assign. If you're building a "grant this user a role" picker, populate it from `assignable()`, not from `roles.list()` — don't assume every role in the system is one this particular admin may hand out.
-
-There is also a CLI read path for the same data, useful outside an app (scripting/inspection): `blocks iam roles list/get/assignable` and `blocks iam permissions list/get/by-severity` — see [manage-roles-permissions.md](manage-roles-permissions.md) for the full CLI command reference (it covers both reads and mutations).
+# Flow: Feature-gating a frontend by the user's own permissions (common, low risk)
+
+This is read-only against IAM and scoped to whoever is signed in, so it needs no special confirmation — build it the same way you'd build any other data-fetching feature.
+
+The scaffold already gives you a `useCurrentUser()` hook (`src/features/profile/useCurrentUser.ts`) wrapping `blocksClient.iam.me()` with TanStack Query; `me()` returns `{ data: { itemId, email, firstName, lastName, roles: string[], permissions: string[], ... } }`. Reuse it instead of re-fetching:
+
+```ts
+// src/features/access/usePermission.ts
+import { useCurrentUser } from "../profile/useCurrentUser";
+
+export function useHasPermission(permission: string): boolean {
+  const me = useCurrentUser();
+  return me.data?.data?.permissions?.includes(permission) ?? false;
+}
+
+export function useHasRole(role: string): boolean {
+  const me = useCurrentUser();
+  return me.data?.data?.roles?.includes(role) ?? false;
+}
+```
+
+```tsx
+// src/shared/ui/RequirePermission.tsx
+import type { ReactNode } from "react";
+import { useHasPermission } from "../../features/access/usePermission";
+
+export function RequirePermission({ permission, children }: { permission: string; children: ReactNode }) {
+  if (!useHasPermission(permission)) return null;
+  return <>{children}</>;
+}
+```
+
+Two more read methods round this out:
+
+- `blocksClient.iam.resources.features(query?)` — feature/resource flags for the active user context; use this to drive nav items or feature flags that are more granular than a flat permission string.
+- `blocksClient.iam.roles.assignable()` — lists roles the **current caller** is allowed to assign. If you're building a "grant this user a role" picker, populate it from `assignable()`, not from `roles.list()` — don't assume every role in the system is one this particular admin may hand out.
+
+There is also a CLI read path for the same data, useful outside an app (scripting/inspection): `blocks iam roles list/get/assignable` and `blocks iam permissions list/get/by-severity` — see [manage-roles-permissions.md](manage-roles-permissions.md) for the full CLI command reference (it covers both reads and mutations).