@seliseblocks/cli-os 0.2.5 → 0.2.7

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

@@ -7,11 +7,12 @@ 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"),
             accessTokenValidForNumberMinutes: optionalIntegerFlag(flags, "access-token-minutes"),
+            accountActionBaseUrl: stringFlag(flags, "account-action-base-url") || undefined,
             accountLockDurationInMinutes: optionalIntegerFlag(flags, "account-lock-duration-minutes"),
             getNumberOfWrongAttemptsToLockTheAccount: optionalIntegerFlag(flags, "wrong-attempts-to-lock"),
             isOidcEnabled: booleanFlag(flags, "oidc-enabled") || undefined,
@@ -21,12 +22,37 @@ 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 };
+    // Turning isOidcEnabled on isn't a single independent flag: the
+    // activation-link flow keys off accountActivationPath, which has to point
+    // at the OIDC variant once OIDC is on, or activation emails break.
+    // accountActionBaseUrl has no safe default this command can guess across
+    // environments, so the caller must supply it explicitly when the tenant
+    // doesn't already have one.
+    const missingActionBaseUrl = Boolean(body.isOidcEnabled) && !body.accountActionBaseUrl;
+    if (body.isOidcEnabled)
+        body.accountActivationPath = "oidc/activate/";
     if (booleanFlag(flags, "dry-run")) {
+        if (missingActionBaseUrl) {
+            console.warn("Warning: this tenant has no accountActionBaseUrl set. Enabling OIDC login requires one -- pass --account-action-base-url <https://your-iam-host> before re-running with --yes.");
+        }
         writeOutput({ dryRun: true, endpoint: "/iam/v4/auth/config", request: body }, flags);
         return;
     }
+    if (missingActionBaseUrl) {
+        throw new Error("Enabling OIDC login requires accountActionBaseUrl, and this tenant doesn't have one set. Pass --account-action-base-url <https://your-iam-host>.");
+    }
     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, oidcUrl, 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,45 @@ 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.
+//
+// Turning isOidcEnabled on isn't a single independent flag either: the
+// activation-link flow keys off accountActivationPath, which has to point at
+// the OIDC variant ("oidc/activate/") once OIDC is on, or activation emails
+// break. accountActionBaseUrl (the host those links are built against) has
+// no safe cross-environment default, but this project's own IAM host is
+// already known here as `oidcUrl`, so it's used whenever the tenant doesn't
+// already have one set.
+async function ensureOidcLoginEnabled(tenantId, oidcUrl, 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,
+            accountActionBaseUrl: config.accountActionBaseUrl || oidcUrl,
+            accountActivationPath: "oidc/activate/",
+            isOidcEnabled: true
+        },
+        impersonatedProjectAuth: true,
+        projectTenantId: tenantId,
+        ...requestContext(flags)
+    });
+}
 function normalizeList(raw) {
     if (Array.isArray(raw))
         return raw;
@@ -135,10 +183,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/skills/blocks-onboarding/SKILL.md

@@ -65,8 +65,8 @@ Run `blocks init` once per project directory to create `blocks.json`, `blocks/da
 
 Then route to what the user actually wants:
 - Building a frontend from scratch → resolve the app's public OIDC client first, then scaffold:
-  - `blocks auth oidc-clients list --json` — check whether a client already registered for this project fits. If none fits, create one directly (no portal visit needed): `blocks auth oidc-clients save --client-display-name <appName> --client-type public --redirect-uris https://<domain>:5173/login/callback --scope "openid profile" --require-pkce --register-as-identity-provider --dry-run --json`, then re-run with `--yes` after showing the dry-run output and getting approval. `--client-type public` is required — IAM derives `tokenEndpointAuthMethod` from it, so omitting it stores a browser client as confidential. `--register-as-identity-provider` creates the linked identity provider in the same call; nothing further to run. See the blocks-iam-sso-oidc-configuration skill for the full decision tree and field-level gotchas.
-  - `blocks new web <name> --x-blocks-key <tenantId> --app-domain <domain> --client-id <the-resolved-client-id>`. **Always pass `--client-id` and `--app-domain` explicitly** — omitting either drops `new web` into an interactive pick-list prompt with no non-interactive escape (not even to "skip"), which hangs a scripted/agent run with no stdin to answer it. Omit `--blocks-api-url` unless the project uses a non-default gateway; the scaffold derives it from the app domain, e.g. `https://dqrsf.slsblx.com` -> `https://blocksapi.slsblx.com`.
+  - `blocks auth oidc-clients list --json` — check whether a client already registered for this project fits. If none fits, create one directly (no portal visit needed): `blocks auth oidc-clients save --client-display-name <appName> --client-type public --redirect-uris https://<domain>:5173/login/callback --scope "openid profile" --require-pkce --register-as-identity-provider --auto-redirect --dry-run --json`, then re-run with `--yes` after showing the dry-run output and getting approval. `--client-type public` is required — IAM derives `tokenEndpointAuthMethod` from it, so omitting it stores a browser client as confidential. `--register-as-identity-provider` creates the linked identity provider in the same call; nothing further to run. `--auto-redirect` matters too — the scaffolded login page already navigates straight to the provider itself, so without it IAM's hosted login page shows a redundant manual "continue" click. When updating an *existing* client instead of creating one, always pass `--item-id` — the save endpoint replaces the whole client document, and the CLI fetches the current one first to merge your change into it rather than resetting the rest. See the blocks-iam-sso-oidc-configuration skill for the full decision tree and field-level gotchas.
+  - `blocks new web <name> --x-blocks-key <tenantId> --app-domain <domain> --client-id <the-resolved-client-id>`. **Always pass `--client-id` and `--app-domain` explicitly** — omitting either drops `new web` into an interactive pick-list prompt with no non-interactive escape (not even to "skip"), which hangs a scripted/agent run with no stdin to answer it. Omit `--blocks-api-url` unless the project uses a non-default gateway; the scaffold derives it from the app domain, e.g. `https://dqrsf.slsblx.com` -> `https://blocksapi.slsblx.com`. Once it resolves the client id, `new web` also checks the tenant's AuthController config and turns on `isOidcEnabled` if it's off — nothing further to do for login to actually work; if you're wiring an existing app instead (`blocks sdk client`, no `new web` call), check that yourself first: `blocks auth config get --json`, and if `isOidcEnabled` is `false`, `blocks auth config save --oidc-enabled --dry-run --json` then `--yes`.
 - Defining data / CRUD / localization / release on an existing project → hand off to the matching skill; the project is already selected via `blocks use`, so its commands can proceed directly.
 
 ## Gotchas

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@seliseblocks/cli-os",
-  "version": "0.2.5",
+  "version": "0.2.7",
   "description": "CLI for SELISE Blocks project setup and configuration.",
   "license": "MIT",
   "type": "module",