Support OpenAPI apiKey security (header/query/cookie) in generated route types and $.auth (and resolve merge conflicts with main)

[Copilot]

Summary

Counterfact previously ignored OpenAPI securitySchemes for apiKey, so generated handlers did not require API key inputs and could not access them via auth context. This change makes apiKey behave like a first-class operation input and exposes it as $.auth.apiKey.

• Generator: synthesize required API key params

  • OperationTypeCoder derives required synthetic parameters from components.securitySchemes entries where type: "apiKey" and in: "header" | "query" | "cookie".
  • These are merged into effective operation parameters with name/location deduping, so generated headers/query/cookie types include required API key fields without duplicate keys.

• Generator: typed auth context

  • Generated operation $ arg includes auth.
  • auth is never when no auth scheme exists, { username?: string; password?: string } for basic auth, { apiKey?: string } for API key, or a merged shape when both exist.

• Runtime: resolve and expose API key

  • OpenApiDocument loads/stores components.securitySchemes.
  • Dispatcher:
    • augments operation parameters with API key requirements (reusing existing request validation),
    • extracts API key from configured header/query/cookie location,
    • injects it into the handler auth object as auth.apiKey.

• Runtime: validate cookie API keys

  • Request validation checks required cookie parameters so missing cookie-based API keys fail consistently with header/query-based keys.

• Merge conflict resolution with latest main

  • Resolved the conflict in operation-type-coder by preserving both:
    • querystring parameter typing introduced on main, and
    • auth typing introduced in this PR.
  • Updated affected snapshots to match the merged behavior.

// generated handler arg now includes auth.apiKey when apiKey security is configured
export const GET: HTTP_GET = ($) => {
  const key = $.auth.apiKey;
  return $.response[200].json({ hasKey: Boolean(key) });
};

Original Prompt

Support for API key

Counterfact doesn't currently read the OpenAPI security object of the OpenAPI schema.

When generating types, it should take that object into account.

For example, if the security object is defined as:

{
  "type": "apiKey",
  "name": "api_key",
  "in": "header"
}

Then Counterfact should act as if every operation has a required request header named "api_key" when generating code.

Follow-up feedback:

• implement spec-correct apiKey behavior for cookie location as well (in: cookie)
• resolve merge conflicts in the pull request

Manual acceptance tests

• With an OpenAPI spec defining components.securitySchemes.apiKeyAuth as type: apiKey, in: header, name: api_key, generated route types require $.headers.api_key.
• With an OpenAPI spec defining components.securitySchemes.apiKeyAuth as type: apiKey, in: cookie, name: api_key_cookie, generated route types require $.cookie.api_key_cookie.
• For header/query/cookie API key schemes, route handlers can read the inbound API key from $.auth.apiKey.
• A request missing the required API key produces request-validation failure mentioning the missing header/query/cookie parameter for the configured location.
• Existing basic-auth behavior remains available: $.auth.username and $.auth.password still populate from Authorization: Basic ....
• After merging latest main, generated operation types still include both querystring typing and auth typing (no regression from conflict resolution).

Tasks

• Added API key security scheme handling in OperationTypeCoder and merged synthetic required params into effective operation parameters.
• Extended synthesized API key parameters to include in: cookie in addition to header and query.
• Added generated auth typing (basic/apiKey/combined) to operation $ argument shape.
• Extended OpenAPI runtime model to retain components.securitySchemes.
• Added dispatcher logic to derive required API key parameters and populate auth.apiKey from header/query/cookie input.
• Updated request validation to enforce required cookie parameters.
• Merged latest main into the branch, resolved the operation-type-coder conflict by keeping both querystring and auth fields, and updated related snapshots/tests.

[pmcelhaney]

Make sure we're implementing the spec correctly. For example, the key can also be in a cookie.

[Copilot]

Make sure we're implementing the spec correctly. For example, the key can also be in a cookie.

Implemented in ca9906e. apiKey security now supports in: cookie in generation and runtime: cookie api keys are added as required operation parameters, validated as required cookie parameters, and exposed via $.auth.apiKey.

[pmcelhaney]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved in 999e3319. I merged latest main, resolved the conflict in src/typescript-generator/operation-type-coder.ts by keeping both querystring and auth typing, and updated snapshots/tests so the branch is conflict-free and passing.