@seliseblocks/cli-os 0.2.6 → 0.2.7

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

@@ -12,6 +12,7 @@ export async function authConfigSave(argv) {
         ...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,
@@ -32,10 +33,25 @@ export async function authConfigSave(argv) {
         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 result = await blocksRequest("/iam/v4/auth/config", {
         body,

package/dist/commands/new/web.js

@@ -23,7 +23,7 @@ export async function newWeb(argv) {
     const oidcClientId = await resolveOidcClientId(tenantId, appDomain, name, flags);
     if (oidcClientId) {
         try {
-            await ensureOidcLoginEnabled(tenantId, flags);
+            await ensureOidcLoginEnabled(tenantId, oidcUrl, flags);
         }
         catch (error) {
             console.warn(`Warning: could not confirm/enable OIDC login on this project's AuthController config: ${error.message}`);
@@ -135,7 +135,15 @@ async function listOidcClientSummaries(tenantId, flags) {
 // 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) {
+//
+// 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,
@@ -145,7 +153,12 @@ async function ensureOidcLoginEnabled(tenantId, flags) {
         return;
     await confirmMutation(flags, "Enable OIDC login on this project's AuthController configuration.");
     await blocksRequest("/iam/v4/auth/config", {
-        body: { ...config, isOidcEnabled: true },
+        body: {
+            ...config,
+            accountActionBaseUrl: config.accountActionBaseUrl || oidcUrl,
+            accountActivationPath: "oidc/activate/",
+            isOidcEnabled: true
+        },
         impersonatedProjectAuth: true,
         projectTenantId: tenantId,
         ...requestContext(flags)

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.6",
+  "version": "0.2.7",
   "description": "CLI for SELISE Blocks project setup and configuration.",
   "license": "MIT",
   "type": "module",