ninepm 0.46.0 → 0.49.0

package/README.md

@@ -108,7 +108,7 @@ Deploy a container app from a local Docker build:
 9pm deploy . --name container-app --slug container-app --runtime container --port 8080 --health-path /health --region auto
 ```
 
-Container deploys require Docker locally. The CLI builds a `linux/amd64` image, exports it, checks image size against the per-app limit and account retained-image quota, uploads through a short-lived session, and finalizes a queued deployment. The container must listen on `0.0.0.0:$PORT` or the selected `--port`; set `--health-path` when the app has a cheap readiness endpoint.
+Container deploys require Docker locally. The CLI builds a `linux/amd64` image, exports it, checks image size against the per-app limit and account retained-image quota, uploads through a short-lived session, and finalizes a queued deployment. The container must listen on `0.0.0.0:$PORT` - always read the `PORT` env var rather than hardcoding the selected `--port`, since on some placements the platform holds the selected port and hands the app a different one; set `--health-path` when the app has a cheap readiness endpoint.
 
 Use `--with-db` when the container needs managed SQL. The app receives `NINEPM_SQL_URL` and `NINEPM_DB_BINDINGS`; send `POST` requests to `NINEPM_SQL_URL` with `{ "binding": "DB", "sql": "SELECT 1", "params": [] }`. For local development, use the app's normal local database adapter behind a repository layer and keep deployed SQL compatible with SQLite.
 

package/dist/index.d.ts

@@ -114,7 +114,7 @@ export interface CreatedServiceToken {
     clientSecret: string;
 }
 export type FetchLike = (input: string | URL | Request, init?: RequestInit) => Promise<Response>;
-export declare const CLI_VERSION = "0.46.0";
+export declare const CLI_VERSION = "0.49.0";
 type CredentialBackend = "macos-keychain" | "windows-dpapi" | "linux-secret-service" | "file-plaintext" | "none";
 export interface StoredCredentialEntry {
     token: string;
@@ -529,6 +529,22 @@ export declare function parseEnvFileEntries(content: string, kind: "secret" | "v
 }>;
 export declare function healthWithReason(status: string | null | undefined, reason: string | null | undefined): string;
 export declare function storedCredentialTokens(): StoredCredentialEntry[];
+/**
+ * Whether a credential provably cannot be stored, decided WITHOUT writing one (#859).
+ *
+ * Deliberately one-directional: it answers only when the answer is certain, and
+ * `preferredCredentialBackend()` is what makes that possible — it reports "none"
+ * exactly when the native store is disabled by env, or the platform has no store
+ * this CLI can reach (Linux without a secret tool, or an unsupported platform).
+ * In those cases `storeSecureCredential` cannot succeed.
+ *
+ * It does NOT try to predict a keychain that exists but errors: on macOS and
+ * Windows the backend is assumed present, so this returns null and the real
+ * failure is caught after the fact. A pre-flight that guessed wrong in the other
+ * direction would refuse a login that would have worked, which is worse than the
+ * browser round-trip it saves.
+ */
+export declare function secureStoreRefusalReason(allowFileFallback?: boolean): string | null;
 export declare function credentialDiagnostics(): CredentialDiagnostics;
 export type BrowserOpenResult = "opened" | "failed" | "unknown";
 export declare function classifyBrowserOpen(input: {

package/dist/index.js

@@ -14,7 +14,7 @@ import { MAX_DEPLOY_DESCRIPTION_LENGTH, normalizeDeployDescription } from "./dep
 import { MAX_STATIC_ASSET_FILE_BYTES, MAX_WORKER_ENTRY_COMPRESSED_BYTES, MAX_WORKER_SCRIPT_COMPRESSED_BYTES, WORKER_ENTRY_COMPRESSED_WARN_BYTES, assetFileTooLargeMessage, formatMebibytes, formatMegabytes, oversizedAssets, workerBundleNearLimitMessage, workerBundleTooLargeMessage, workerEntryNearLimitMessage, workerEntryTooLargeMessage, } from "./deploy-limits.js";
 import { buildFileManifest, readManifestFile } from "./manifest.js";
 import { API_KEY_HELP, API_URL_HELP, CLI_CLIENT_ID, DEFAULT_API_URL, reportCliError } from "./cli-config.js";
-export const CLI_VERSION = "0.46.0";
+export const CLI_VERSION = "0.49.0";
 const PUBLIC_DASHBOARD_URL = "https://9pm.ai/dashboard";
 const TOKEN_SERVICE = "9pm";
 const TOKEN_ACCOUNT = "default";
@@ -710,6 +710,12 @@ export function publicWhoamiResult(result) {
 // and never answers). Longer than the 5s reachability probe because this
 // request is worth waiting for, but still bounded.
 const REVOKE_TIMEOUT_MS = 10_000;
+// The post-storage identity lookup's bound (#859). Same reasoning and same value as
+// the revocation above — a hung connection must degrade this call, not the login it
+// decorates. Kept separate so shortening one does not silently shorten the other:
+// this one only costs the account name, while that one decides whether a live
+// credential is given back.
+const IDENTITY_TIMEOUT_MS = 10_000;
 // Revoke the API key `options.token` authenticates as (#822). The token itself
 // carries no key id, so /v1/me — whose response names the calling key — is how
 // the CLI learns which row to revoke. Every branch returns instead of throwing:
@@ -1035,6 +1041,11 @@ export async function signupDevice(options) {
 async function deviceAuthFlow(options) {
     const fetchFn = options.fetchFn ?? fetch;
     const apiUrl = normalizeApiUrl(options.apiUrl);
+    // #859: refuse before the browser round-trip when the credential provably has
+    // nowhere to go. The control plane mints the key inside the poll and consumes the
+    // authorization with it, so approving first and discovering this afterwards leaves
+    // a live key the user never received and cannot revoke. Only a certain refusal is
+    // made here; an unpredictable store failure is caught after the poll instead.
     const startResponse = await fetchFn(`${apiUrl}/v1/oauth/device/start`, {
         method: "POST",
         headers: { "content-type": "application/json" },
@@ -1052,6 +1063,27 @@ async function deviceAuthFlow(options) {
     if (!userCode || !deviceCode) {
         throw new Error(`Device ${options.purpose} response did not include a device code.`);
     }
+    // #859: refuse before the browser round-trip when the credential provably has
+    // nowhere to go. The control plane mints the key inside the POLL and consumes the
+    // authorization with it, so approving first and discovering this afterwards leaves
+    // a live key the user never received and cannot revoke. Only a certain refusal is
+    // made here; an unpredictable store failure is caught after the poll instead.
+    //
+    // Deliberately AFTER the start response rather than before it: that response is
+    // what carries the actionable refusal for a signup that can never be approved
+    // (#507), and a storage complaint arriving first would send the user to fix their
+    // keychain only to learn afterwards that signup was closed all along. Nothing is
+    // minted at start, so the ordering costs nothing but a lapsed pending
+    // authorization.
+    //
+    // Skipped when the caller injects its own store: that seam replaces the credential
+    // backend wholesale, so probing the real one says nothing about whether the
+    // caller's will work — and refusing on its behalf would be a refusal we cannot
+    // justify.
+    const refusal = options.storeCredentialFn ? null : secureStoreRefusalReason(options.allowFileCredentialStore);
+    if (refusal) {
+        throw new Error(refusal);
+    }
     console.log(`Open ${start.verification_uri}`);
     console.log(`Device code: ${userCode}`);
     // Everything new below goes to stderr (#509): stdout keeps exactly the two
@@ -1118,14 +1150,72 @@ async function deviceAuthFlow(options) {
             // login (#514 review). stop() is idempotent, so the finally below stays as
             // the fallback for every other exit path.
             progress.stop();
-            const storage = (options.storeCredentialFn ?? storeCredential)(poll.token, {
-                allowFileFallback: options.allowFileCredentialStore,
-                // Recorded so logout can revoke against the control plane that issued
-                // this credential rather than whatever URL it resolves later.
-                apiUrl,
-            });
-            const me = await whoami({ apiUrl, token: poll.token, fetchFn });
-            return { email: me.user.email, storage };
+            let storage;
+            try {
+                storage = (options.storeCredentialFn ?? storeCredential)(poll.token, {
+                    allowFileFallback: options.allowFileCredentialStore,
+                    // Recorded so logout can revoke against the control plane that issued
+                    // this credential rather than whatever URL it resolves later.
+                    apiUrl,
+                });
+            }
+            catch (error) {
+                // #859: the key exists on the account by now, and this process is the only
+                // thing that will ever hold its token — the poll consumed the authorization,
+                // so a retry cannot re-deliver it and the user cannot revoke what they never
+                // saw. Give it back before failing.
+                const revocation = await revokeCredential({
+                    apiUrl,
+                    token: poll.token,
+                    ...(options.fetchFn ? { fetchFn: options.fetchFn } : {}),
+                });
+                discardRevokedCredential(poll.token);
+                throw new Error(unstorableCredentialMessage(error, revocation));
+            }
+            // The identity lookup is decoration: the credential is stored, so a transient
+            // failure must not fail the login — that would send the user back to `login`,
+            // mint a second key and orphan this one, which is this issue in reverse (#859).
+            // An authentication refusal is not transient, though: it proves the stored
+            // credential cannot authenticate, and reporting "logged in" for it would be a
+            // lie the user only discovers on their next command. The response is read
+            // directly rather than through whoami because the status reaches whoami's
+            // caller only as prose inside an error message.
+            let identity;
+            try {
+                identity = await fetchFn(`${apiUrl}/v1/me`, {
+                    method: "GET",
+                    headers: jsonHeaders(poll.token),
+                    // Bounded for the same reason the revocation calls are: a black-holed
+                    // connection accepts TCP and never answers. Unbounded, this would not fail
+                    // the login — it would wedge it open indefinitely, which is worse than the
+                    // graceful warning this branch exists to give. The timeout lands in the
+                    // catch below and degrades to "signed in, name unavailable".
+                    signal: AbortSignal.timeout(IDENTITY_TIMEOUT_MS),
+                });
+            }
+            catch {
+                identity = null;
+            }
+            if (identity && (identity.status === 401 || identity.status === 403) && (await isAuthRefusal(identity))) {
+                const revocation = await revokeCredential({
+                    apiUrl,
+                    token: poll.token,
+                    ...(options.fetchFn ? { fetchFn: options.fetchFn } : {}),
+                });
+                discardRevokedCredential(poll.token);
+                throw new Error(joinSentences("The credential this login created was stored but cannot authenticate.", disposalSentence(revocation)));
+            }
+            if (!identity?.ok) {
+                // Said out loud rather than swallowed: the login DID succeed, and the user
+                // should know which half of it did not.
+                progressStream.write(`Warning: signed in, but could not read the account name (${identity ? `the control plane answered ${identity.status}` : "the request failed"}).\n`);
+                return { storage };
+            }
+            const email = await identity
+                .json()
+                .then((body) => body.user?.email)
+                .catch(() => undefined);
+            return email ? { email, storage } : { storage };
         }
     }
     finally {
@@ -2452,6 +2542,11 @@ async function runLogsCommand(command) {
             placement_unsupported: "Runtime logs are not yet available for this app's placement.",
             not_configured: "Runtime logs are not configured on this platform.",
             nothing_retained: "No recent runtime output is retained for the serving deployment.",
+            // #853: distinct from the line above on purpose. The provider IS holding output for
+            // this app - it just all belongs to a different deployment than the one serving, which
+            // is what a failed retry leaves behind. Telling the owner their app printed nothing
+            // would be false, and it is the sentence that sent one incident out of band.
+            not_this_version: "The retained output all belongs to another deployment of this app, not the one serving now.",
             provider_unavailable: "Runtime logs are temporarily unavailable; try again shortly.",
         };
         console.log("");
@@ -2879,13 +2974,101 @@ function safeApiUrl(value) {
         return undefined;
     }
 }
+/**
+ * What became of the key a failed login had already been issued (#859).
+ *
+ * Reported rather than assumed: when giving it back fails, the user is the only one
+ * who can finish the job, and saying nothing would leave a live full-scope credential
+ * they have no reason to go looking for.
+ */
+function disposalSentence(revocation) {
+    return revocation.kind === "failed"
+        ? `The credential this login created could NOT be revoked automatically (${revocation.reason}) — revoke it from Settings in the dashboard, or it stays valid.`
+        : "The credential this login created has been revoked, so nothing was left active.";
+}
+// Join two sentences without doubling or dropping the separator: a store failure's
+// message may or may not end in punctuation ("EACCES: permission denied, open '…'"
+// does not), and the result is read by a person.
+function joinSentences(first, second) {
+    const head = first.trim();
+    return `${head}${/[.!?]$/.test(head) ? "" : "."} ${second}`;
+}
+/**
+ * Remove any credential that holds a token we have just revoked (#859).
+ *
+ * `storePlaintextCredential` writes the token file before its metadata, so a store
+ * that threw part-way can leave the new token on disk — over the top of whatever
+ * valid credential was there. Left alone, every later command would authenticate
+ * with a dead key.
+ *
+ * Every store is matched on its OWN value rather than cleared as a group. The three
+ * of them (native, plaintext, legacy) can hold different tokens, and only the token
+ * this login minted has been revoked: sweeping them together would delete a
+ * different, still-valid credential locally without revoking it — turning one
+ * orphan into two, which is the failure this whole change exists to stop.
+ *
+ * The shared metadata file is deliberately left alone for the same reason: it
+ * describes whichever credential survives, and a stale backend hint is a much
+ * cheaper wrong than erasing a live session's record.
+ */
+function discardRevokedCredential(token) {
+    if (readSecureCredential() === token) {
+        // One platform's store exists per host; the others no-op, as at logout.
+        deleteMacKeychainCredential();
+        deleteWindowsDpapiCredential();
+        deleteLinuxSecretServiceCredential();
+        deleteSecureIssuer();
+    }
+    for (const entry of readPlaintextCredentials()) {
+        if (entry.token === token) {
+            removeFileIfExists(entry.path);
+        }
+    }
+}
+/**
+ * What to tell a user whose credential was issued but could not be stored (#859).
+ * The store failure leads, because it is the part they can act on.
+ */
+function unstorableCredentialMessage(storeError, revocation) {
+    const cause = storeError instanceof Error ? storeError.message : String(storeError);
+    return joinSentences(cause, disposalSentence(revocation));
+}
+// One message for both the pre-flight refusal and the real store's failure, so the
+// two can never drift into telling a user different things about the same state.
+function secureStoreUnavailableMessage() {
+    return `Secure credential storage is unavailable. Re-run with --allow-file-credential-store or set ${ALLOW_FILE_CREDENTIAL_STORE_ENV}=1 to store a plaintext fallback file.`;
+}
+/**
+ * Whether a credential provably cannot be stored, decided WITHOUT writing one (#859).
+ *
+ * Deliberately one-directional: it answers only when the answer is certain, and
+ * `preferredCredentialBackend()` is what makes that possible — it reports "none"
+ * exactly when the native store is disabled by env, or the platform has no store
+ * this CLI can reach (Linux without a secret tool, or an unsupported platform).
+ * In those cases `storeSecureCredential` cannot succeed.
+ *
+ * It does NOT try to predict a keychain that exists but errors: on macOS and
+ * Windows the backend is assumed present, so this returns null and the real
+ * failure is caught after the fact. A pre-flight that guessed wrong in the other
+ * direction would refuse a login that would have worked, which is worse than the
+ * browser round-trip it saves.
+ */
+export function secureStoreRefusalReason(allowFileFallback) {
+    if (preferredCredentialBackend() !== "none") {
+        return null;
+    }
+    if (isFileCredentialStoreAllowed(allowFileFallback)) {
+        return null;
+    }
+    return secureStoreUnavailableMessage();
+}
 function storeCredential(token, options = {}) {
     const secure = storeSecureCredential(token, options.apiUrl);
     if (secure) {
         return secure;
     }
     if (!isFileCredentialStoreAllowed(options.allowFileFallback)) {
-        throw new Error(`Secure credential storage is unavailable. Re-run with --allow-file-credential-store or set ${ALLOW_FILE_CREDENTIAL_STORE_ENV}=1 to store a plaintext fallback file.`);
+        throw new Error(secureStoreUnavailableMessage());
     }
     return storePlaintextCredential(token, options.apiUrl);
 }
@@ -3961,7 +4144,7 @@ Size limits:
 
 Container deploys:
   Requires Docker locally. The CLI builds linux/amd64, exports the image, uploads it through a short-lived session, then finalizes a queued deployment.
-  The app must listen on 0.0.0.0:$PORT or the selected --port. Use --health-path for a cheap readiness endpoint.
+  The app must listen on 0.0.0.0:$PORT - always read the PORT env var; on some placements the platform holds the selected --port and hands the app a different one. Use --health-path for a cheap readiness endpoint.
   With --with-db, containers receive NINEPM_SQL_URL and NINEPM_DB_BINDINGS for the managed SQL bridge.
   With --with-auth, the app gets 9pm-managed end-user accounts (email one-time codes); it implies --with-db and is one-way (enable-only).
   With --with-email, a signed-in end user can send app invitation emails; it implies --with-auth and works on public apps only.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ninepm",
-  "version": "0.46.0",
+  "version": "0.49.0",
   "description": "CLI for deploying built apps to 9pm.ai.",
   "homepage": "https://9pm.ai",
   "keywords": [