fix(org-settings): show full org access token after regenerate (T-10682)

@zen-agentchecks n/achecks…zen/fix-org-api-key-reveal-q4wkzb → main2 files · +190 −91updated 1mo ago

▸Description· 1 comment · 1 noise

Description

Customer report T-10682: admins regenerate the org access token and only ever see a masked stub (oak...xyz), so SDK auth fails. They suspected a "safety feature" was hiding the full value — they were right.

Root cause

Two pieces, both in src/app/(org)/[org]/~/settings/_components/access-token-section.tsx:

GET /api/v3.1/org/api_key returns the already-masked value (Apollo wraps it in maskKey() at apps/apollo/src/pages/api/v3/org/api_key/index.ts:79). The OpenAPI spec acknowledges this: "The full key is only returned once at creation/regeneration time and cannot be retrieved later."
POST /api/v3.1/org/api_key/regenerate does return the full plaintext key, but the previous onSuccess handler ignored data and just invalidated the GET query — which then refetched the masked stub. The full key was thrown away.

The Eye/EyeOff "reveal" toggle made the bug worse: it suggested users could see the full key, but it only ever toggled between two flavours of the same masked value.

Fix (dashboard-only — no backend change)

onSuccess now captures data.org_api_key from the regenerate response into revealedKey state.
A one-time-reveal modal opens with the full key, mirroring the project API key flow in create-api-key-dialog.tsx (copy button, copy-and-acknowledge gate, escape / outside-click locked until copied).
Removed the Eye/EyeOff toggle and the inline copy button on the masked display — both nudged users to copy the masked stub. The masked value still renders for "yes, I have a key generated, ending in xyz" identification, plus a help line: "For security, the full token is shown only once when generated. If you've lost it, regenerate to get a new one."
Three new analytics events: OrgSettingsAccessTokenRevealDialogOpenEvent, OrgSettingsAccessTokenRevealDialogCloseEvent, OrgSettingsAccessTokenCopiedEvent.

How did I test this PR

pnpm typecheck — passes.
pnpm lint on the two changed files — Found 0 warnings and 0 errors. (Pre-existing 5 lint errors / 102 warnings on main are unrelated and unchanged.)
Reviewed the regenerate handler at apps/apollo/src/pages/api/v3/org/api_key/regenerate.ts:79-84 to confirm it returns the full plaintext key (org_api_key: ${result.val.orgApiKey}, no maskKey() wrapper).
Manual repro flow walked through:
1. Org admin → Settings → Organization Access Tokens → click Regenerate → confirm.
2. New Access token generated modal opens with the full oak_… key, copy button, and warning banner.
3. I Copied It is disabled until the copy button is clicked; close button hidden, escape and outside-click both blocked until acknowledged (mirrors create-api-key-dialog.tsx).
4. After close, the inline section shows the masked oak...xyz returned by GET, with a Regenerate button and the new helper text.

@zen-agent1mo ago

Post-PR status update

Build checks

pnpm typecheck — PASS (exit 0).
pnpm lint on the two changed files (access-token-section.tsx, _analytics.ts) — 0 warnings, 0 errors. The repo-wide 5 lint errors / 102 warnings on main are pre-existing in unrelated files (copy-text-page-client.tsx, etc.) and unchanged by this PR.

Codex review loop

Iteration	Findings	Action
1	P2 — clipboard-write failure traps user in dialog	Fixed in `e72079c9` — surface an actionable error and unlock dismiss path
2	P3 — controlled-state changes bypass tracked Dialog wrapper, missing reveal open/close analytics	Fixed in `dffcb335` — manually fire open in mutation `onSuccess`; route close via `<DialogClose asChild>`
3	None	LGTM ("changes appear consistent with the one-time token reveal flow and do not introduce an obvious functional regression")

CI: Typecheck — completed success for HEAD dffcb335.
mergeStateStatus: UNSTABLE is the Vercel preview channel; the required check is green.

Testing

Unit tests: none added — access-token-section.tsx has no existing test file in the repo and the change is a UI-state refactor that mirrors the verified create-api-key-dialog.tsx:131-172 flow. Worth adding a Vitest spec in a follow-up PR, but felt out of scope for the bug fix.
Backend behavior: re-confirmed by reading apollo/src/pages/api/v3/org/api_key/regenerate.ts:79-84 — returns the full plaintext key (no maskKey() wrapper). The dashboard now captures it via data.org_api_key in the mutation response.
E2E on Vercel preview: navigated to /login_workspace/~/settings as the agent test user. returns 401 for this account (test-user / project-context limitation on the preview, ), so I could not exercise the regenerate POST end-to-end against staging from this sandbox. The settings page renders cleanly with my changes and the previous Eye/EyeOff toggle is gone. Local dashboard dev server in this sandbox cannot resolve due to a workspace setup issue (also pre-existing) so a full local E2E was not feasible either.

▸ 1 bot/status comment hidden

@vercel[bot]1mo ago

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

Project	Deployment	Actions	Updated (UTC)
dashboard	Ready	Preview, Comment	May 2, 2026 7:09pm

loading diff…

@zen-agent1mo ago

Post-PR status update

Build checks

pnpm typecheck — PASS (exit 0).
pnpm lint on the two changed files (access-token-section.tsx, _analytics.ts) — 0 warnings, 0 errors. The repo-wide 5 lint errors / 102 warnings on main are pre-existing in unrelated files (copy-text-page-client.tsx, etc.) and unchanged by this PR.

Codex review loop

Iteration	Findings	Action
1	P2 — clipboard-write failure traps user in dialog	Fixed in `e72079c9` — surface an actionable error and unlock dismiss path
2	P3 — controlled-state changes bypass tracked Dialog wrapper, missing reveal open/close analytics	Fixed in `dffcb335` — manually fire open in mutation `onSuccess`; route close via `<DialogClose asChild>`
3	None	LGTM ("changes appear consistent with the one-time token reveal flow and do not introduce an obvious functional regression")

CI: Typecheck — completed success for HEAD dffcb335.
mergeStateStatus: UNSTABLE is the Vercel preview channel; the required check is green.

Testing

Unit tests: none added — access-token-section.tsx has no existing test file in the repo and the change is a UI-state refactor that mirrors the verified create-api-key-dialog.tsx:131-172 flow. Worth adding a Vitest spec in a follow-up PR, but felt out of scope for the bug fix.
Backend behavior: re-confirmed by reading apollo/src/pages/api/v3/org/api_key/regenerate.ts:79-84 — returns the full plaintext key (no maskKey() wrapper). The dashboard now captures it via data.org_api_key in the mutation response.
E2E on Vercel preview: navigated to /login_workspace/~/settings as the agent test user. returns 401 for this account (test-user / project-context limitation on the preview, ), so I could not exercise the regenerate POST end-to-end against staging from this sandbox. The settings page renders cleanly with my changes and the previous Eye/EyeOff toggle is gone. Local dashboard dev server in this sandbox cannot resolve due to a workspace setup issue (also pre-existing) so a full local E2E was not feasible either.