feat(api-keys): support runtime key creation - #87
Conversation
|
The x64 smoke probe repeatedly received connection resets; all other #87 checks passed. The same code also passed x64 Docker on stacked PR #88, so this appears transient rather than change-related. GitHub rejected both the direct rerun and retry push, and no remote state changed. PR #87 remains blocked on the original failed check. A maintainer needs to select Re-run failed jobs on the workflow run. |
Greptile SummaryThe PR adds organization- and user-scoped runtime API-key creation, user-scoped listing, expiration, and live authentication registration.
Confidence Score: 3/5This PR should not merge until deleting a user or organization also revokes its runtime-created API keys. The new routes place owner-linked secrets in the live authentication allow-list, but both owner-deletion paths leave those entries intact, so credentials for deleted principals continue to authorize requests. Files Needing Attention: src/workos/routes/api-keys.ts, src/workos/routes/users.ts, src/workos/routes/organizations.ts
|
| Filename | Overview |
|---|---|
| src/workos/routes/api-keys.ts | Adds runtime key lifecycle routes, but newly owner-linked credentials are not integrated with owner-deletion cleanup. |
| src/core/middleware/auth.ts | Correctly treats an expiry equal to the current time as expired. |
| src/workos/routes/api-keys.spec.ts | Covers creation, listing, expiration, and authentication, but not revocation after owner deletion. |
| scripts/gen-supported-lib.ts | Updates the generated support note to reflect runtime-created credentials. |
| SUPPORTED.md | Records the newly implemented API-key endpoint coverage. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Create API key] --> B[API-key record]
A --> C[Live authentication map]
D[Delete user or organization] --> E[Delete owner and existing cascades]
E -. missing cleanup .-> B
E -. missing revocation .-> C
C --> F[Orphaned key still authenticates]
Prompt To Fix All With AI
### Issue 1
src/workos/routes/api-keys.ts:47-52
**Owner deletion leaves credentials**
When a user or organization owning a runtime-created API key is deleted, the deletion cascades remove neither the key record nor its live allow-list entry, causing the orphaned key to continue authenticating protected requests. The creation path needs corresponding owner-deletion cleanup for both stores.
**How this was verified:** The owner-deletion handlers omit both `apiKeyRecords` and `apiKeyMap`, while authentication continues accepting every unexpired entry retained in that map.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "feat(api-keys): support runtime key crea..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| permissions: (body.permissions as string[] | undefined) ?? [], | ||
| last_used_at: null, | ||
| expires_at: (expiresAt as string | undefined) ?? null, | ||
| }); | ||
| const apiKeyMap = store.getData<ApiKeyMap>(STORE_KEYS.apiKeyMap) ?? {}; | ||
| apiKeyMap[value] = { environment, expiresAt: record.expires_at }; |
There was a problem hiding this comment.
When a user or organization owning a runtime-created API key is deleted, the deletion cascades remove neither the key record nor its live allow-list entry, causing the orphaned key to continue authenticating protected requests. The creation path needs corresponding owner-deletion cleanup for both stores.
How this was verified: The owner-deletion handlers omit both apiKeyRecords and apiKeyMap, while authentication continues accepting every unexpired entry retained in that map.
Knowledge Base Used:
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/workos/routes/api-keys.ts
Line: 47-52
Comment:
**Owner deletion leaves credentials**
When a user or organization owning a runtime-created API key is deleted, the deletion cascades remove neither the key record nor its live allow-list entry, causing the orphaned key to continue authenticating protected requests. The creation path needs corresponding owner-deletion cleanup for both stores.
**How this was verified:** The owner-deletion handlers omit both `apiKeyRecords` and `apiKeyMap`, while authentication continues accepting every unexpired entry retained in that map.
**Knowledge Base Used:**
- [State storage and seed data](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/emulate/-/docs/state-storage-and-seeding.md)
- [Organizations, users, and memberships](https://app.greptile.com/workos/-/custom-context/knowledge-base/workos/emulate/-/docs/organizations-users-and-memberships.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.There was a problem hiding this comment.
Valid and already fixed locally in commit 95ed139:
- Revokes user-owned keys when deleting a user.
- Revokes organization- and member-owned keys when deleting an organization.
- Removes both stored records and live authentication entries.
- Adds regression coverage; 69 focused tests pass.
This Greptile comment still targets remote SHA 5a12133 because GitHub rejected TARS’s push. PR #87 remains unchanged; a verified human follow-up is required before TARS can retry publishing the fix.
|
Local commit
GitHub rejected the push with HTTP 403. PR #87 therefore remains at |
Summary
SUPPORTED.mdTracks FEAT-3028.
Validation
bun test src/workos/routes/api-keys.spec.ts src/workos/seed-m2m.spec.ts src/workos/response-envelopes.spec.tsbun run typecheckbun run lintbun run fmt:checkRequested by garen.torikian@workos.com via TARS