[DX-1123] fix(auth): redesign revoke-token to match Ably revocation API semantics by sacOO7 · Pull Request #364 · ably/ably-cli

sacOO7 · 2026-04-21T17:51:28Z

Fixes https://ably.atlassian.net/browse/DX-1123
Link to internal discussion -> https://ably-real-time.slack.com/archives/C04KNCEP4RH/p1776855422090079
Removed existing Token argument and added mutually exclusive client-id and revocation-key, optional allow-reauth-margin flag.
Tested on the local, all flags working as expected

Issue token => pnpm cli auth issue-ably-token --capability '{"*":["*"]}'
Subscribe to channel using token => ABLY_TOKEN="Issued Token" pnpm cli channels subscribe my-channel --pretty-json
Revoke token => pnpm cli auth revoke-token --client-id "client-id-from-issued-token"

Summary

auth revoke-token: Added --force flag and interactive confirmation prompt — this was the only hard-delete command missing the safety pattern. In JSON mode, --force is required to prevent accidental scripted revocations.
Removed misleading positional token arg — the Ably token revocation API
does not support revoking a single token by its string value. It only supports
clientId and revocationKey target specifiers
(see docs).
Added --client-id and --revocation-key flags — mutually exclusive,
at least one required. Validated in code with a helpful error message linking
to the docs.
Added --allow-reauth-margin flag — maps to the API's allowReauthMargin
parameter, giving connected clients a 30-second grace period to obtain a new
token before disconnection.
Removed dead code — the command was creating an Ably Realtime client
(createAblyRealtimeClient) that was never used; the actual API call is a
raw HTTPS request.
Fixed component string inconsistency — standardized all this.fail()
calls to use "revokeToken".
auth keys revoke: Replaced interactiveHelper.confirm() with promptForConfirmation() to match the pattern used by all other destructive commands.
Updated tests: all existing revoke-token tests now pass --force, added coverage for JSON mode guard and user cancellation flow.

vercel · 2026-04-21T17:51:32Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
cli-web-cli	Ready	Preview, Comment	Apr 30, 2026 0:11am

claude-code-ably-assistant · 2026-04-21T17:52:20Z

Walkthrough

This PR closes a safety gap in auth revoke-token, which was the only hard-delete command missing the --force / interactive confirmation pattern used by every other destructive command. It also replaces the bespoke interactiveHelper.confirm() call in auth keys revoke with the shared promptForConfirmation() utility to standardise the prompting pattern across both revoke commands.

Changes

Area	Files	Summary
Commands	`src/commands/auth/revoke-token.ts`	Add `--force` flag, JSON-mode guard (errors without `--force`), interactive confirmation prompt before revocation, and updated examples
Commands	`src/commands/auth/keys/revoke.ts`	Swap `interactiveHelper.confirm()` → `promptForConfirmation()` and align prompt wording
Tests	`test/unit/commands/auth/revoke-token.test.ts`	Add `--force` to all existing test invocations; add two new tests: JSON-mode guard and user-cancellation flow

Review Notes

Breaking change for scripted use: auth revoke-token now requires --force when --json is passed. Any existing scripts calling ably auth revoke-token TOKEN --json will now fail with an error envelope instead of silently revoking. This is intentional and consistent with the pattern on other destructive commands, but warrants a mention in release notes.
Interactive confirmation wording: revoke-token now shows a truncated token preview before asking for confirmation. Worth checking that the truncation (token.slice(0, 15) + "...") is sufficient to identify the token without leaking sensitive material.
Stdin patching in tests: The cancellation test directly mutates process.stdin to simulate user input. This is a side-effectful approach — confirm it doesn't leave state that could affect other tests in the suite (there is a restore at the end, but the queueMicrotask timing is worth scrutinising).
No new dependencies: uses existing promptForConfirmation utility and forceFlag — no package changes required.

Copilot

Pull request overview

Adds the standard “destructive action safety” pattern to auth revoke-token and aligns auth keys revoke with the shared confirmation-prompt helper, with corresponding unit test updates.

Changes:

Added --force flag + interactive confirmation prompt to auth revoke-token, including a JSON-mode guard that requires --force.
Switched auth keys revoke confirmation from interactiveHelper.confirm() to promptForConfirmation() for consistency.
Updated/extended unit tests to pass --force where required and to cover JSON guard + user-cancel flows.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
`src/commands/auth/revoke-token.ts`	Adds `--force`, JSON guard, and interactive confirmation before revoking tokens.
`src/commands/auth/keys/revoke.ts`	Standardizes the destructive confirmation prompt helper.
`test/unit/commands/auth/revoke-token.test.ts`	Updates existing tests for new `--force` requirement and adds new coverage for guard/cancel behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…dize keys revoke prompt - Add `--force` flag and interactive confirmation prompt to `auth revoke-token` (the only hard-delete command missing the safety pattern) - Require `--force` in JSON mode to prevent accidental scripted revocations - Replace `interactiveHelper.confirm()` with `promptForConfirmation()` in `auth keys revoke` for consistency with all other destructive commands - Update tests with new --force flag and add coverage for JSON guard and cancellation flow

sacOO7 · 2026-04-22T07:52:21Z

@claude review

claude-code-ably-assistant

Review: fix(auth): add --force flag to revoke-token, standardize keys revoke prompt

The core change is correct and necessary. Adding --force to auth revoke-token was the right fix — it was the only hard-delete command missing this safety pattern. The JSON-mode guard and interactive confirmation flow are implemented correctly and mirror what other destructive commands do.

Two issues worth addressing:

1. Incomplete standardization in `keys/revoke.ts` — second `interactiveHelper.confirm()` left unchanged

The PR standardizes the primary revocation prompt (line ~76) to promptForConfirmation(), but the secondary prompt at line ~112 still uses this.interactiveHelper.confirm() (inquirer):

// Line ~112 — unchanged in this PR
const shouldRemove = await this.interactiveHelper.confirm(
  "The revoked key was your current key for this app. Remove it from configuration?",
);

interactiveHelper.confirm uses inquirer, while promptForConfirmation uses readline. These behave differently in non-TTY environments — inquirer may throw or hang, while readline degrades gracefully. In a single command run, the user now hits two different prompt UX implementations back-to-back. If the stated goal is to standardize on promptForConfirmation, this second call should be updated too.

2. Cancellation test uses fragile stdin monkey-patching

it("should cancel when user declines confirmation", async () => {
  // replaces process.stdin with a Readable and pushes "n\n" via queueMicrotask
  mockStdinAnswer("n");
  ...
  const { stderr } = await runCommand([...]);
  expect(stderr).toContain("Revocation cancelled");
  expect(revokeNock.isDone()).toBe(false);
});

This works due to Node.js Readable stream buffering (data is pushed before readline attaches), but it is fragile: any refactor of promptForConfirmation (e.g., switching to inquirer or a different input mechanism) would silently break this test without a compile error. The idiomatic approach is to mock the function itself:

import * as promptModule from "../../../utils/prompt-confirmation.js";
vi.spyOn(promptModule, "promptForConfirmation").mockResolvedValueOnce(false);

This makes the test's intent explicit and decouples it from the implementation details of how stdin is read.

Both issues are fixable before merge. The feature itself is correct.

AndyTWF · 2026-04-22T08:08:17Z

Looks like there's a couple of Claude comments so will hold off the review til those are addressed :)

…mation at all places

…ve prompt

sacOO7 · 2026-04-22T08:46:42Z

@claude review

Copilot

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…key flags

sacOO7 · 2026-04-23T07:21:27Z

Two issues reported by claude are not real issues. Still I have addressed both. The first one Pre-confirmation context uses this.log() is already used by other commands like apps/delete, queues/delete etc

sacOO7 · 2026-04-23T13:56:47Z

Tested on the local, all flags working as expected 👍
Commands

Issue token => pnpm cli auth issue-ably-token --capability '{"*":["*"]}'
Subscribe to channel using token => ABLY_TOKEN="Issued Token" pnpm cli channels subscribe my-channel --pretty-json
Revoke token => pnpm cli auth revoke-token --client-id "client-id-from-issued-token"

…gin is set

…-confirmation-prompt

AndyTWF · 2026-04-29T15:32:35Z

+      description: "Revoke all tokens issued to this client ID",
+      exclusive: ["revocation-key"],
+    }),
+    "revocation-key": Flags.string({


Question, should these be mandatory mutally exclusive flags, or would it even be better to have separate commands, e.g. revoke-token by-clientid, revoke-token by-key ?

I looked at OCLIF_AUTOGENERATED_DOC.md for all commands, we have no by-* subcommand pattern anywhere. All commands follow the pattern, and targeting/filtering is always done via flags (--client-id, --device-id, --type, --prefix, etc.). Introducing by-* subcommands here would break that consistency.

revocation-key is only valid for JWT tokens with following criteria

To designate a revocation key, include the following additional claim in the JWT: - `x-ably-revocation-key`: a string used to identify which token(s) to revoke in the revocation request. This target specifier will match tokens that have the specified `revocationKey`.

Each flag is designed for a specific use case, so they are kept mutually exclusive.

I'm fine with how this is done currently e.g.

Manual mandatory check (if (!clientId && !revocationKey)) instead of exactlyOne - we get slightly better help formatting using our manual check instead of the oclif property... also this is a codebase wide standard we can revisit later if we want (not important for GA)

Correct use of the exclusive property

I also agree using the flags is better than having separate commands. It just makes more sense in the CLI.

One thing I would change... the fail message needs updating to match what we do elsewhere...

it is currently ""Either --client-id or --revocation-key is required. See https://ably.com/docs/auth/revocation for details."

However:

We don't add doc urls in any fail messages - this should be removed.

"Either --client-id or --revocation-key must be provided" follows the language of other similar fail messages

Fixed a3e41c2

umair-ably · 2026-04-30T09:46:49Z

    }),
-
    "client-id": Flags.string({
      char: "c",


I know you didn't touch this, but we don't actually shorthand client-d anywhere else in the codebase... i'd push to remove this here altogether

umair-ably · 2026-04-30T09:47:51Z

+      exclusive: ["revocation-key"],
+    }),
+    "revocation-key": Flags.string({
+      char: "r",


given the client-id shorthand will be removed, i'd also remove this tbh

umair-ably · 2026-04-30T09:48:39Z

-        const confirmed = await this.interactiveHelper.confirm(
-          "This will permanently revoke this key and any applications using it will stop working. Continue?",
+        const confirmed = await promptForConfirmation(
+          "\nThis will permanently revoke this key and any applications using it will stop working. Are you sure?",


Suggested change

"\nThis will permanently revoke this key and any applications using it will stop working. Are you sure?",

"\nThis will permanently revoke this key and any applications using it will stop working. Are you sure you want to continue?",

umair-ably · 2026-04-30T09:52:38Z

+    "allow-reauth-margin": Flags.boolean({
+      default: false,
+      description:
+        "[default: false] Delay enforcement by 30s so connected clients can obtain a new token before disconnection.",


The presence of this flag means it is enabled, meaning the absence is a default of false. Having the false default in the description is confusing imo - pretty sure we follow this standard for all default: false flags

Suggested change

"[default: false] Delay enforcement by 30s so connected clients can obtain a new token before disconnection.",

"Delay enforcement by 30s so connected clients can obtain a new token before disconnection.",

umair-ably · 2026-04-30T10:00:47Z

can you ensure you run /ably-review locally... there's a couple of issues around swallowing error context and formatting it should pick up (Opus 4.7 xHigh Effort)

…ages as per review comments

sacOO7 · 2026-04-30T11:31:45Z

can you ensure you run /ably-review locally... there's a couple of issues around swallowing error context and formatting it should pick up (Opus 4.7 xHigh Effort)

Ran /ably-review with Opus 4.7 xHigh Effort, found minor issues, fixed -> e20f8a4

Out of date review, all changes are well addressed

vercel Bot deployed to Preview April 21, 2026 17:51 View deployment

sacOO7 requested a review from Copilot April 21, 2026 17:52

Copilot started reviewing on behalf of sacOO7 April 21, 2026 17:52 View session

This comment was marked as outdated.

Sign in to view

Copilot AI reviewed Apr 21, 2026

View reviewed changes

Comment thread src/commands/auth/revoke-token.ts Outdated

Comment thread test/unit/commands/auth/revoke-token.test.ts Outdated

sacOO7 force-pushed the fix/revoke-token-with-confirmation-prompt branch from 0ab3a37 to 736ff38 Compare April 21, 2026 18:27

vercel Bot deployed to Preview April 21, 2026 18:28 View deployment

sacOO7 force-pushed the fix/revoke-token-with-confirmation-prompt branch from 736ff38 to e4c0028 Compare April 22, 2026 07:48

vercel Bot deployed to Preview April 22, 2026 07:48 View deployment

sacOO7 requested review from AndyTWF and umair-ably April 22, 2026 07:51

claude-code-ably-assistant Bot reviewed Apr 22, 2026

View reviewed changes

sacOO7 changed the title ~~fix(auth): add --force flag to revoke-token, standardize keys revoke prompt~~ [DX-1123] fix(auth): add --force flag to revoke-token, standardize keys revoke prompt Apr 22, 2026

sacOO7 added 2 commits April 22, 2026 14:10

Replaced use of this.interactiveHelper.confirm with promptForConfir…

6bed655

…mation at all places

Updated AGENTS.md with recommended usage of force flag with interacti…

6a35954

…ve prompt

sacOO7 requested a review from Copilot April 22, 2026 08:46

vercel Bot deployed to Preview April 22, 2026 08:47 View deployment

Copilot started reviewing on behalf of sacOO7 April 22, 2026 08:47 View session

Copilot AI reviewed Apr 22, 2026

View reviewed changes

Comment thread src/commands/auth/revoke-token.ts Outdated

Comment thread src/commands/auth/revoke-token.ts

This comment was marked as off-topic.

Sign in to view

sacOO7 changed the title ~~[DX-1123] fix(auth): add --force flag to revoke-token, standardize keys revoke prompt~~ [DX-1123] fix(auth): redesign revoke-token to match Ably revocation API semantics Apr 22, 2026

vercel Bot deployed to Preview April 22, 2026 13:45 View deployment

fix(auth): redesign revoke-token to use --client-id and --revocation-…

855a69a

…key flags

sacOO7 force-pushed the fix/revoke-token-with-confirmation-prompt branch from ee013f5 to 855a69a Compare April 22, 2026 13:52

Applied claude review comments

46a8e72

sacOO7 force-pushed the fix/revoke-token-with-confirmation-prompt branch from 871d9be to 46a8e72 Compare April 22, 2026 15:14

vercel Bot deployed to Preview April 22, 2026 15:15 View deployment

Added explicit note related to 30s grace period when allow-reauth-mar…

27c8a4e

…gin is set

vercel Bot deployed to Preview April 23, 2026 14:18 View deployment

Merge remote-tracking branch 'origin/main' into fix/revoke-token-with…

0c0c10b

…-confirmation-prompt

vercel Bot deployed to Preview April 29, 2026 04:31 View deployment

Added missing e2e tests for keys revoke token

7b124f8

vercel Bot deployed to Preview April 29, 2026 07:46 View deployment

sacOO7 mentioned this pull request Apr 29, 2026

[DX-1143] Docs: add environment variables usage documentation #373

Merged

AndyTWF reviewed Apr 29, 2026

View reviewed changes

umair-ably reviewed Apr 30, 2026

View reviewed changes

Fixed auth keys revoke command shorthands, description and error mess…

a3e41c2

…ages as per review comments

vercel Bot deployed to Preview April 30, 2026 10:32 View deployment

vercel Bot deployed to Preview April 30, 2026 11:24 View deployment

Fixed revoke-token output message and updated tests as per ably-review

c46534f

sacOO7 force-pushed the fix/revoke-token-with-confirmation-prompt branch from e20f8a4 to c46534f Compare April 30, 2026 12:10

vercel Bot deployed to Preview April 30, 2026 12:11 View deployment

umair-ably approved these changes Apr 30, 2026

View reviewed changes

sacOO7 merged commit 80d8cf0 into main Apr 30, 2026
11 checks passed

sacOO7 deleted the fix/revoke-token-with-confirmation-prompt branch April 30, 2026 12:31

sacOO7 mentioned this pull request May 1, 2026

chore: prepare release 1.0.0 #380

Merged

6 tasks

	"\nThis will permanently revoke this key and any applications using it will stop working. Are you sure?",
	"\nThis will permanently revoke this key and any applications using it will stop working. Are you sure you want to continue?",

	"[default: false] Delay enforcement by 30s so connected clients can obtain a new token before disconnection.",
	"Delay enforcement by 30s so connected clients can obtain a new token before disconnection.",

Conversation

sacOO7 commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

vercel Bot commented Apr 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claude-code-ably-assistant Bot commented Apr 21, 2026

Walkthrough

Changes

Review Notes

Uh oh!

This comment was marked as outdated.

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

sacOO7 commented Apr 22, 2026

Uh oh!

claude-code-ably-assistant Bot left a comment

Choose a reason for hiding this comment

Review: fix(auth): add --force flag to revoke-token, standardize keys revoke prompt

1. Incomplete standardization in keys/revoke.ts — second interactiveHelper.confirm() left unchanged

2. Cancellation test uses fragile stdin monkey-patching

Uh oh!

AndyTWF commented Apr 22, 2026

Uh oh!

sacOO7 commented Apr 22, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

This comment was marked as off-topic.

Uh oh!

sacOO7 commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sacOO7 commented Apr 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sacOO7 Apr 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

umair-ably commented Apr 30, 2026

Uh oh!

sacOO7 commented Apr 30, 2026

Uh oh!

sacOO7 commented Apr 21, 2026 •

edited

Loading

vercel Bot commented Apr 21, 2026 •

edited

Loading

1. Incomplete standardization in `keys/revoke.ts` — second `interactiveHelper.confirm()` left unchanged

sacOO7 commented Apr 23, 2026 •

edited

Loading

sacOO7 commented Apr 23, 2026 •

edited

Loading

sacOO7 Apr 30, 2026 •

edited

Loading