Skip to content

[codex] Fix OpenAPI multi-key auth inputs#1151

Merged
RhysSullivan merged 1 commit into
mainfrom
fix-openapi-multi-key-inputs
Jun 26, 2026
Merged

[codex] Fix OpenAPI multi-key auth inputs#1151
RhysSullivan merged 1 commit into
mainfrom
fix-openapi-multi-key-inputs

Conversation

@RhysSullivan

Copy link
Copy Markdown
Owner

Summary

Fixes OpenAPI-derived API key auth methods that require multiple header credentials, using Cloudflare legacy auth as the regression case.

Root cause: the OpenAPI auth derivation treated every header in one detected header preset as the same implicit token input. That preserved both outbound header placements, but the connection modal correctly grouped them into one credential field because both placements referenced the same variable.

Changes

  • Derive stable per-header variables for multi-header OpenAPI API key strategies, while keeping single-header methods on the conventional token input.
  • Flatten the multi-credential Add connection UI so it shows one Credential section with simple side-by-side fields instead of nested cards or duplicate preview chrome.
  • Add Cloudflare real-spec regression coverage for X-Auth-Email + X-Auth-Key.
  • Add a browser e2e scenario that creates a Cloudflare-shaped OpenAPI integration, opens the Add connection modal, and verifies the two separate credential fields.

Recording

OpenAPI · the Cloudflare email and key auth method shows separate credential fields (cloud)

Validation

  • bunx vitest run src/sdk/real-specs.test.ts in packages/plugins/openapi
  • bun run test in packages/plugins/openapi
  • bun run typecheck in packages/plugins/openapi
  • bunx vitest run src/components/add-account-modal.test.ts in packages/react
  • bunx vitest run --project cloud scenarios/openapi-multi-key-auth-ui.test.ts in e2e
  • bunx vitest run --project selfhost scenarios/openapi-multi-key-auth-ui.test.ts in e2e
  • bunx tsc --noEmit in e2e
  • bunx oxfmt --check packages/react/src/components/add-account-modal.tsx e2e/scenarios/openapi-multi-key-auth-ui.test.ts packages/plugins/openapi/src/sdk/derive-auth.ts packages/plugins/openapi/src/sdk/real-specs.test.ts .changeset/openapi-multi-key-auth.md
  • git diff --check -- packages/react/src/components/add-account-modal.tsx packages/plugins/openapi/src/sdk/derive-auth.ts packages/plugins/openapi/src/sdk/real-specs.test.ts e2e/scenarios/openapi-multi-key-auth-ui.test.ts .changeset/openapi-multi-key-auth.md

@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Preview URL Updated (UTC)
✅ Deployment successful!
View logs
executor-marketing f8c383c Commit Preview URL

Branch Preview URL
Jun 26 2026, 09:13 PM

@cloudflare-workers-and-pages

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status Name Latest Commit Updated (UTC)
✅ Deployment successful!
View logs
executor-cloud f8c383c Jun 26 2026, 09:14 PM

@github-actions

github-actions Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Cloudflare preview

Torn down — the PR is closed.

@RhysSullivan RhysSullivan marked this pull request as ready for review June 26, 2026 21:15
@RhysSullivan RhysSullivan merged commit 4b361b9 into main Jun 26, 2026
14 checks passed
@greptile-apps

greptile-apps Bot commented Jun 26, 2026

Copy link
Copy Markdown

Greptile Summary

Fixes OpenAPI-derived multi-header API key auth (regression case: Cloudflare X-Auth-Email + X-Auth-Key) by deriving a stable, slug-safe variable name per header when a security strategy requires more than one header, while keeping single-header methods on the conventional token input for backward compatibility.

  • derive-auth.ts: adds slugifyVariable + variablesForHeaders; apiKeyTemplateFromHeaderPreset now emits per-header variable properties for multi-header presets only.
  • add-account-modal.tsx: PasteCredentialInputs branches on singleInput; the multi-input path renders a labeled grid and hides the redundant placement-preview row; the single-input path is unchanged.
  • Regression coverage added via a Cloudflare real-spec unit test and a browser E2E scenario that verifies both credential inputs appear in the Add connection modal.

Confidence Score: 4/5

Safe to merge; core auth derivation and modal UI are correct and well-tested.

The fix is narrowly scoped: multi-header paths get unique variable names, single-header paths are untouched. The E2E scenario and real-spec test cover the Cloudflare regression end-to-end. The one minor nit is tautological isVisible() assertions in the browser test after waitFor() calls already confirm visibility.

No files require special attention; add-account-modal.tsx has the broadest surface area but the change is a clean branch split with no shared-state mutation.

Important Files Changed

Filename Overview
packages/plugins/openapi/src/sdk/derive-auth.ts Adds slugifyVariable and variablesForHeaders helpers; updates apiKeyTemplateFromHeaderPreset to emit per-header variable names for multi-header presets while keeping single-header methods on the conventional token input. Logic is correct and collision-safe.
packages/react/src/components/add-account-modal.tsx Splits PasteCredentialInputs into a grid multi-input path and the original single-input path; hides the placement preview row for multi-input methods. Change is clean and does not break the 1Password gate or createCredentialPayloadOrigin logic.
packages/plugins/openapi/src/sdk/real-specs.test.ts Adds a regression assertion that deriveAuthenticationTemplateFromPreview produces two separate per-header placements (x_auth_email, x_auth_key) for Cloudflare's legacy multi-header auth strategy.
e2e/scenarios/openapi-multi-key-auth-ui.test.ts Browser E2E scenario covering the Cloudflare-shaped multi-key auth UI; uses the correct Effect service-as-capability pattern and cleanup via Effect.ensuring. Minor: two isVisible() assertions are tautological given preceding waitFor() calls.
.changeset/openapi-multi-key-auth.md Patch-level changeset entry for @executor-js/plugin-openapi; description matches the scope of the change.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[OpenAPI spec parsed] --> B{secretHeaders count}
    B -- "= 1 single-header" --> C[variablesForHeaders returns empty map]
    B -- "greater than 1 multi-header" --> D[variablesForHeaders returns slugified map]
    C --> E[placement has no variable property]
    D --> F[placement gets variable = slugifyHeader name]
    E --> G[singleInput = true]
    F --> H[singleInput = false]
    G --> I[Single password input, conventional token variable, PlacementLine preview shown]
    H --> J[Grid of labeled password inputs one per header, PlacementLine preview hidden]
    I --> K[payload values = token]
    J --> L[payload values = x_auth_email x_auth_key etc]
    K --> M[addConnection API call]
    L --> M
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[OpenAPI spec parsed] --> B{secretHeaders count}
    B -- "= 1 single-header" --> C[variablesForHeaders returns empty map]
    B -- "greater than 1 multi-header" --> D[variablesForHeaders returns slugified map]
    C --> E[placement has no variable property]
    D --> F[placement gets variable = slugifyHeader name]
    E --> G[singleInput = true]
    F --> H[singleInput = false]
    G --> I[Single password input, conventional token variable, PlacementLine preview shown]
    H --> J[Grid of labeled password inputs one per header, PlacementLine preview hidden]
    I --> K[payload values = token]
    J --> L[payload values = x_auth_email x_auth_key etc]
    K --> M[addConnection API call]
    L --> M
Loading

Reviews (1): Last reviewed commit: "Fix OpenAPI multi-key auth inputs" | Re-trigger Greptile

Comment on lines +82 to +91
"the modal renders one secret input for each required header",
).toBe(2);
expect(
await dialog.getByPlaceholder("paste X-Auth-Email").isVisible(),
"email has its own input",
).toBe(true);
expect(
await dialog.getByPlaceholder("paste X-Auth-Key").isVisible(),
"API key has its own input",
).toBe(true);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Tautological visibility assertions after waitFor()

waitFor() with its default state ("visible") already confirms each element is present and visible. The two isVisible() checks below add no assertion value and do not improve failure messages over the waitFor() lines above them. Per the AGENTS.md quality bar ("no tautologies — don't assert what the setup already guarantees"), these can be removed; the count() assertion plus waitFor() already pin the exact UI state the test needs to prove.

Context Used: e2e/AGENTS.md (source)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant