Make Swagger UI actually send the x-api-key header - #269
Conversation
…routes The scheme was registered without a name, so it landed in the OpenAPI doc as api_key and no operation referenced it. Swagger UI stored the key but never sent the header. Name the scheme x-api-key and add ApiSecurity to every AuthGuard route, mirroring the existing ApiBearerAuth placement. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughSwagger now registers the ChangesSwagger security metadata
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
api/src/main.ts (1)
44-51: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a Swagger security contract test.
The changed behavior is visible in the generated OpenAPI document. Add a test that asserts
components.securitySchemes['x-api-key']uses an API key in thex-api-keyheader. Also assert that guarded operations reference this scheme and public auth operations remain unsecured.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@api/src/main.ts` around lines 44 - 51, Add a Swagger/OpenAPI contract test for the configuration passed to addApiKey, asserting components.securitySchemes['x-api-key'] is an apiKey scheme located in the x-api-key header. Also verify guarded operations reference this security scheme while public authentication operations remain unsecured.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@api/src/main.ts`:
- Around line 44-51: Add a Swagger/OpenAPI contract test for the configuration
passed to addApiKey, asserting components.securitySchemes['x-api-key'] is an
apiKey scheme located in the x-api-key header. Also verify guarded operations
reference this security scheme while public authentication operations remain
unsecured.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 55d135af-7acc-4ac2-856e-824206a23831
📒 Files selected for processing (6)
api/src/auth/auth.controller.tsapi/src/billing/billing.controller.tsapi/src/gateway/gateway.controller.tsapi/src/main.tsapi/src/support/support.controller.tsapi/src/webhook/webhook.controller.ts
Fixes #154, closes #258.
Root cause
main.tsregistered the API key scheme via.addApiKey({...})without a name, so it ended up in the OpenAPI doc under the default nameapi_key, and no operation ever referenced it (there was not a single@ApiSecurityin the repo, controllers only carried@ApiBearerAuth). A security scheme that no operation references means Swagger UI renders the Authorize box, stores the key, and never adds the header to any request. That is exactly the behavior reported in #154, and #258 has the full write-up.Changes
securitySchemes['x-api-key']:.addApiKey({ type: 'apiKey', name: 'x-api-key', in: 'header' }, 'x-api-key')@ApiSecurity('x-api-key')to every route guarded byAuthGuard(which accepts either a Bearer JWT or an x-api-key), mirroring the existing@ApiBearerAuthplacement:GatewayController,WebhookController,BillingControllerAuthController(only the guarded routes; login/register/reset stay public, andverify-emailkeeps bearer only since it has no guard)SupportControllerhad no swagger auth annotations at all, socustomer-supportgets both decorators andrequest-account-deletion(JwtAuthGuard) gets@ApiBearerAuthonlyVerification
pnpm buildpasses, and all 73 auth-related unit tests pass[{"x-api-key":[]},{"bearer":[]}], public routes are unchangedx-api-keyheader go out in devtools🤖 Generated with Claude Code
Summary by CodeRabbit