wood-fired-tasks 2.0.2 → 2.0.4

package/CHANGELOG.md

@@ -13,6 +13,51 @@ vulnerabilities, supply-chain pinning) are always called out under `Security`.
 
 _No changes yet._
 
+## [v2.0.4] - 2026-06-08
+
+### Fixed
+- **Device-flow `verification_uri` now points at the address the client actually
+  connected to, not `localhost`.** `POST /auth/device/code` built the URL the
+  user opens in a browser from a STATIC configured origin (`OIDC_REDIRECT_URI`'s
+  origin), which is typically `http://localhost:3000`. A CLI that reached the
+  server over the LAN (e.g. `http://192.168.x.x:3000`) was told to open a
+  `localhost` URL pointing at its OWN machine — a dead end. The origin is now
+  derived per-request from the `Host` header (honoring `X-Forwarded-Host` /
+  `X-Forwarded-Proto` from a trusted reverse proxy), falling back to the
+  configured origin only when no `Host` is present. This is not a
+  host-header-injection vector: the `verification_uri` is returned only to the
+  same client that made the request. (Note: a Google-backed server whose OAuth
+  callback is `http://localhost` still can't complete the *browser login* leg
+  for a remote client — Google forbids non-`localhost` `http` redirect URIs — so
+  remote clients should use `tasks setup --remote <url> --token <pat>` or an
+  HTTPS domain. This fix makes the verification URL correct for properly
+  routable servers.)
+
+## [v2.0.3] - 2026-06-08
+
+### Fixed
+- **`tasks setup` device-flow login no longer fails with `invalid_client` on
+  servers backed by a real IdP.** The RFC 8628 device-flow `client_id` was
+  validated against `OIDC_CLIENT_ID` — the *IdP's* OAuth client id used for the
+  browser SSO leg — while the CLI sends a logical `'wft-cli'`. On any server
+  using e.g. Google, those never matched, so `POST /auth/device/code` returned
+  `400 invalid_client` and setup crashed. The device-flow client id is now a
+  **separate** setting, `OIDC_DEVICE_CLIENT_ID` (defaults to `'wft-cli'` on both
+  server and CLI), decoupled from `OIDC_CLIENT_ID` and not part of the
+  all-or-nothing OIDC group — so the stock CLI authenticates against a stock
+  server with no configuration. Operators who customize it set the same value
+  on both sides.
+- **Remote onboarding degrades gracefully when the device flow can't start.**
+  A failed/throwing `POST /auth/device/code` (e.g. `invalid_client`, or a
+  network error) previously aborted `tasks setup` with a raw stack-trace-style
+  error. It now logs the reason and falls back to manual personal-access-token
+  entry, so onboarding can still complete.
+
+### Changed
+- New optional env var **`OIDC_DEVICE_CLIENT_ID`** (default `'wft-cli'`),
+  documented in `docs/SETUP.md`. No action required for existing deployments
+  using the default CLI.
+
 ## [v2.0.2] - 2026-06-08
 
 ### Fixed

package/dist/api/routes/auth/device-code.d.ts

@@ -26,9 +26,15 @@
 import type { FastifyPluginAsync } from 'fastify';
 export interface DeviceCodeRouteOptions {
     /**
-     * Server origin used to build the verification URIs the CLI prints. Plan
-     * 30-08 sources this from `new URL(env.OIDC_REDIRECT_URI).origin`.
-     * Example: `https://woodfiredbugs.local`.
+     * FALLBACK origin for the verification URIs the CLI prints, used only when
+     * the request carries no usable Host header. Plan 30-08 sources this from
+     * `new URL(env.OIDC_REDIRECT_URI).origin`. Example: `https://woodfiredbugs.local`.
+     *
+     * #834: the verification origin is now derived PER-REQUEST from the address
+     * the client actually connected to (see {@link resolveVerificationOrigin}),
+     * because this configured value is typically `http://localhost:3000` and is
+     * unroutable for any client that reached the server over the LAN / a real
+     * hostname. `origin` remains as the no-Host-header fallback.
      */
     origin: string;
     /**
@@ -37,5 +43,25 @@ export interface DeviceCodeRouteOptions {
      */
     expectedClientId: string;
 }
+/**
+ * Resolve the origin (`scheme://host[:port]`) the CLIENT used to reach this
+ * server, for building the device-flow `verification_uri` the user opens in a
+ * browser (#834).
+ *
+ * Previously this was a STATIC configured origin (`OIDC_REDIRECT_URI`'s origin),
+ * which is `http://localhost:3000` on a typical server — so a CLI that connected
+ * over the LAN (e.g. `http://192.168.x.x:3000`) was told to open a localhost URL
+ * pointing at its OWN machine. We instead use the host the request arrived on,
+ * honoring `X-Forwarded-{Host,Proto}` from a trusted reverse proxy.
+ *
+ * Security: this is NOT a host-header-injection vector. The `verification_uri`
+ * is returned ONLY to the same client that sent the request, so a spoofed Host
+ * merely misdirects the spoofer. Falls back to `fallback` (the configured
+ * origin) when no Host header is present at all.
+ */
+export declare function resolveVerificationOrigin(request: {
+    headers: Record<string, string | string[] | undefined>;
+    protocol?: string;
+}, fallback: string): string;
 declare const deviceCodeRoute: FastifyPluginAsync<DeviceCodeRouteOptions>;
 export default deviceCodeRoute;

package/dist/api/routes/auth/device-code.js

@@ -1,5 +1,38 @@
 import { z } from 'zod';
 import { createSession } from '../../../services/device-flow-store.js';
+/** First value of a possibly comma-joined / array-valued HTTP header. */
+function firstHeaderValue(v) {
+    const raw = Array.isArray(v) ? v[0] : v;
+    if (typeof raw !== 'string')
+        return undefined;
+    const first = raw.split(',')[0]?.trim();
+    return first && first.length > 0 ? first : undefined;
+}
+/**
+ * Resolve the origin (`scheme://host[:port]`) the CLIENT used to reach this
+ * server, for building the device-flow `verification_uri` the user opens in a
+ * browser (#834).
+ *
+ * Previously this was a STATIC configured origin (`OIDC_REDIRECT_URI`'s origin),
+ * which is `http://localhost:3000` on a typical server — so a CLI that connected
+ * over the LAN (e.g. `http://192.168.x.x:3000`) was told to open a localhost URL
+ * pointing at its OWN machine. We instead use the host the request arrived on,
+ * honoring `X-Forwarded-{Host,Proto}` from a trusted reverse proxy.
+ *
+ * Security: this is NOT a host-header-injection vector. The `verification_uri`
+ * is returned ONLY to the same client that sent the request, so a spoofed Host
+ * merely misdirects the spoofer. Falls back to `fallback` (the configured
+ * origin) when no Host header is present at all.
+ */
+export function resolveVerificationOrigin(request, fallback) {
+    const host = firstHeaderValue(request.headers['x-forwarded-host']) ??
+        firstHeaderValue(request.headers['host']);
+    if (!host)
+        return fallback;
+    const scheme = firstHeaderValue(request.headers['x-forwarded-proto']) ??
+        (request.protocol && request.protocol.length > 0 ? request.protocol : 'http');
+    return `${scheme}://${host}`;
+}
 /**
  * Body schema for POST /auth/device/code (JSON only — RFC 8628 lets servers
  * pick; the CLI always sends JSON). `scope` is accepted-and-ignored in v1.6
@@ -37,11 +70,15 @@ const deviceCodeRoute = async (fastify, opts) => {
             clientId: client_id,
             hostname: hostname ?? null,
         }, 'device flow started');
+        // #834: build the verification URL from the address the CLIENT connected to
+        // (request Host / X-Forwarded-*), not the static configured origin, so a
+        // remote/LAN client gets a URL it can actually open instead of localhost.
+        const origin = resolveVerificationOrigin(request, opts.origin);
         return reply.code(200).send({
             device_code: session.deviceCode,
             user_code: session.userCode,
-            verification_uri: `${opts.origin}/auth/device`,
-            verification_uri_complete: `${opts.origin}/auth/device?user_code=${session.userCode}`,
+            verification_uri: `${origin}/auth/device`,
+            verification_uri_complete: `${origin}/auth/device?user_code=${session.userCode}`,
             expires_in: 600,
             interval: 5,
         });

package/dist/api/server.js

@@ -362,6 +362,11 @@ export async function createServer(options) {
                 }, 'device-flow origin resolved to localhost — CLI verification_uri will be unroutable for remote clients');
             }
             const clientId = config.OIDC_CLIENT_ID;
+            // #833: the device-flow `client_id` is a SEPARATE logical identifier the
+            // CLI sends (default `'wft-cli'`), NOT the IdP's OAuth client id. Using
+            // OIDC_CLIENT_ID here rejected the stock CLI with `invalid_client` on any
+            // real-IdP server. Always defaulted, so device flow works out of the box.
+            const deviceClientId = config.OIDC_DEVICE_CLIENT_ID;
             await server.register(authRoutes, {
                 prefix: '/auth',
                 oidcConfig: app.oidcConfig,
@@ -413,9 +418,9 @@ export async function createServer(options) {
                 await scope.register(authPlugin);
                 await scope.register(deviceCodeRoute, {
                     origin,
-                    expectedClientId: clientId,
+                    expectedClientId: deviceClientId,
                 });
-                await scope.register(deviceTokenRoute, { expectedClientId: clientId });
+                await scope.register(deviceTokenRoute, { expectedClientId: deviceClientId });
                 await scope.register(deviceHtmlRoute, { origin });
             });
         }

package/dist/cli/commands/setup.js

@@ -809,32 +809,53 @@ export async function runRemoteOnboarding(options = {}) {
         log('This server supports browser login (OIDC ready); using the device flow.');
     }
     // 3. Branch on the selected method.
-    const method = selectRemoteOnboardingMethod(probeResult);
+    let method = selectRemoteOnboardingMethod(probeResult);
     const oidc = probeResult.ok ? probeResult.oidc : null;
     if (method === 'device-flow') {
         // Self-provision a PAT via the OIDC device flow (#806). runDeviceLogin owns
         // the entire RFC 8628 exchange AND persists the minted PAT via the
         // credentials writer (writeCredentials) — there is NO host token-mint path
-        // here. On failure it has already emitted its own error output; we just
-        // propagate ok:false without writing anything.
-        const result = await deviceLogin({
-            baseUrl,
-            clientId: process.env['OIDC_CLIENT_ID'] ?? 'wft-cli',
-            hostname: os.hostname(),
-            openBrowser: true,
-            isJson: false,
-        });
-        if (!result.ok) {
-            return { mode: 'remote', oidc, method, ok: false };
+        // here.
+        //
+        // client_id (#833): send the DEVICE-flow client id (`OIDC_DEVICE_CLIENT_ID`,
+        // default `'wft-cli'`), NOT the IdP's `OIDC_CLIENT_ID`. The server validates
+        // it against its own `OIDC_DEVICE_CLIENT_ID` (also defaulting to `'wft-cli'`),
+        // so the stock CLI matches a stock server out of the box.
+        let deviceOk = false;
+        try {
+            const result = await deviceLogin({
+                baseUrl,
+                clientId: process.env['OIDC_DEVICE_CLIENT_ID'] ?? 'wft-cli',
+                hostname: os.hostname(),
+                openBrowser: true,
+                isJson: false,
+            });
+            deviceOk = result.ok;
+            if (!deviceOk) {
+                log('Browser/device login did not complete; falling back to manual PAT entry.');
+            }
+        }
+        catch (err) {
+            // #833: device/code can hard-reject (e.g. a client_id mismatch →
+            // `invalid_client`) or the network can fail. Don't crash setup — degrade
+            // to manual personal-access-token entry so onboarding can still finish.
+            const message = err instanceof Error ? err.message : String(err);
+            log(`Browser/device login could not start (${message}).`);
+            log('Falling back to manual personal-access-token entry.');
+        }
+        if (deviceOk) {
+            // Device login succeeded and the PAT is already persisted in the
+            // credentials file. Now write the URL-only remote MCP entry (#810) into
+            // ~/.claude.json. The entry carries ONLY WFT_API_URL — the bridge resolves
+            // its bearer token at runtime from the credentials file the device flow
+            // just wrote, so NO token is ever embedded in claude.json and NO PAT is
+            // double-cached here.
+            const setup = writeRemoteMcpEntryOnly({ ...options, remote: baseUrl });
+            return { mode: 'remote', oidc, method, ok: true, setup };
         }
-        // Device login succeeded and the PAT is already persisted in the
-        // credentials file. Now write the URL-only remote MCP entry (#810) into
-        // ~/.claude.json. The entry carries ONLY WFT_API_URL — the bridge resolves
-        // its bearer token at runtime from the credentials file the device flow
-        // just wrote, so NO token is ever embedded in claude.json and NO PAT is
-        // double-cached here.
-        const setup = writeRemoteMcpEntryOnly({ ...options, remote: baseUrl });
-        return { mode: 'remote', oidc, method, ok: true, setup };
+        // Device flow unavailable/aborted → fall through to the manual-PAT path
+        // below (records the method actually used so the result reflects reality).
+        method = 'manual-pat';
     }
     // method === 'manual-pat' (task #809): obtain a PAT, validate it, and persist
     // it through the SAME credentials writer the device flow uses

package/dist/config/env.d.ts

@@ -79,6 +79,7 @@ export declare const configSchema: z.ZodObject<{
     OIDC_CLIENT_ID: z.ZodOptional<z.ZodString>;
     OIDC_CLIENT_SECRET: z.ZodOptional<z.ZodString>;
     OIDC_REDIRECT_URI: z.ZodOptional<z.ZodString>;
+    OIDC_DEVICE_CLIENT_ID: z.ZodDefault<z.ZodString>;
     OIDC_POST_LOGOUT_REDIRECT_URI: z.ZodOptional<z.ZodString>;
     OIDC_SCOPES: z.ZodDefault<z.ZodString>;
     OIDC_DISCOVERY_MAX_ATTEMPTS: z.ZodPipe<z.ZodDefault<z.ZodString>, z.ZodTransform<number, string>>;

package/dist/config/env.js

@@ -108,6 +108,16 @@ export const configSchema = z
     OIDC_CLIENT_ID: z.string().min(1).optional(),
     OIDC_CLIENT_SECRET: z.string().min(1).optional(),
     OIDC_REDIRECT_URI: z.string().url().optional(),
+    // RFC 8628 device-flow client_id (#833). DISTINCT from OIDC_CLIENT_ID: the
+    // latter is the IdP's OAuth client id used for the BROWSER SSO leg
+    // (`/auth/login` → Google), which is opaque to the CLI. The device-flow
+    // `client_id` is a logical identifier the CLI and server agree on out of
+    // band; the `tasks` CLI sends `'wft-cli'` by default. Conflating the two
+    // (the original Plan-30-08 wiring used OIDC_CLIENT_ID for both) made the
+    // device flow reject the CLI's default `client_id` with `invalid_client`
+    // on any server backed by a real IdP. Defaulted so it works with the
+    // stock CLI and is NOT part of the all-or-nothing OIDC group.
+    OIDC_DEVICE_CLIENT_ID: z.string().min(1).default('wft-cli'),
     // WR-03 fix — `post_logout_redirect_uri` for RP-initiated logout.
     // Optional: when absent, the wiring at src/api/server.ts derives a
     // default from OIDC_REDIRECT_URI's origin (+ `/auth/login`). Sourcing

package/docs/SETUP.md

@@ -332,6 +332,14 @@ OIDC_REDIRECT_URI=http://localhost:3000/auth/callback
 # Optional — defaults to "openid email profile". The server requires at
 # minimum "openid email" to map the OIDC subject to a local user row.
 OIDC_SCOPES=openid email profile
+
+# Optional — defaults to "wft-cli". The RFC 8628 device-flow client_id the
+# `tasks` CLI sends during `tasks setup` → Remote. DISTINCT from OIDC_CLIENT_ID
+# (the IdP's OAuth client id for the browser SSO leg): the device flow uses a
+# logical client id the CLI and server agree on. Leave unset on both sides to
+# use the default — the stock CLI then authenticates out of the box. Override
+# only if you also set OIDC_DEVICE_CLIENT_ID to a matching value on the client.
+OIDC_DEVICE_CLIENT_ID=wft-cli
 ```
 
 ### 3. Generate the session cookie secret

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wood-fired-tasks",
-  "version": "2.0.2",
+  "version": "2.0.4",
   "description": "Network-wide task tracking system for Wood Fired Games",
   "keywords": [
     "task-tracker",