Skip to content

v1.5.4

Latest

Choose a tag to compare

@github-actions github-actions released this 10 Jun 22:24
2e3041a

Patch Changes

  • #943 f485e4a Thanks @RhysSullivan! - One auth model across OpenAPI, GraphQL, and MCP

    • Every protocol plugin now stores the same placements-based auth methods (the new @executor-js/sdk/http-auth vocabulary): an API-key method carries any mix of header and query placements, each rendered from its own credential input — so one source can declare OAuth, a bearer-header-plus-team-id-query method, a plain bearer, and a query token side by side, and one connection can carry several values (e.g. both Datadog keys).
    • MCP and GraphQL gain what only OpenAPI could do before: multi-placement methods, query-parameter credentials (servers like ui.sh's ?token=), and multi-input connections. Rendering, catalog projection, slug normalization, and the React method editor/codec are shared instead of triplicated; the connect modal collects one value per input.
    • Invoking with an unresolvable credential input now fails with connection_value_missing (naming the missing inputs) instead of silently dialing unauthenticated.
    • Stored integration configs are rewritten to the canonical shape by a one-off migration: local and self-host run it automatically at startup; cloud operators run bun run db:migrate-auth:prod before deploying. Connection bindings and stored credential values are preserved exactly.
    • Authoring: apikey methods are authored in ONE request-shaped dialect on every plugin — it reads like the request it produces: { type: "apiKey", headers: { Authorization: ["Bearer ", variable("token")] }, queryParams: { team_id: [variable("team_id")] } } (variable() is exported from each plugin; a plain-string value is a static literal). Inputs normalize to the canonical placements model, which is what stored configs and the catalog read as. Authoring is strict where the renderer is: a value carries at most one variable, as the final part.
    • Every method is keyed by kind — OpenAPI's oauth templates re-key from the retired type: "oauth" spelling to kind: "oauth2" (matching MCP/GraphQL); the one-off migration rewrites stored entries.
    • Breaking (wire): the retired single-placement inputs (headerName on MCP, in/name on GraphQL), raw canonical-placement inputs, and type: "oauth" oauth inputs are rejected. The mcp.addServer singular auth shorthand still works.
  • #950 dbb48ec Thanks @RhysSullivan! - Fix: workspace connections were resolvable only by whoever created them

    The WorkOS Vault credential provider filed a credential's metadata under the acting user's private partition instead of the credential's own owner. Org-shared connections (and OAuth tokens, and OAuth client secrets) created by one member therefore resolved only for that member — every other member of the workspace hit connection_value_missing ("no resolvable credential value") even though the key was saved correctly. The provider now partitions by the owner embedded in the credential's item id (connection:org:… → org-shared, connection:user:… → private), so a key pasted by one member works for the whole workspace. Pre-existing mis-filed metadata is repaired by a one-off cloud migration (db:repartition-vault:prod); the stored secret value itself was never affected.

  • Updated dependencies []:

    • @executor-js/local@1.4.4
    • @executor-js/sdk@1.5.4
    • @executor-js/runtime-quickjs@1.5.4
    • @executor-js/api@1.4.26