feat(wasm): per-request credentials from session variables

[codybrom]

What kind of change does this PR introduce?

Feature. Adds a generic host function for reading a Postgres session variable at request time, plus an OpenAPI FDW option that uses it as the auth credential.

My use case is per-user access in a multi-tenant app. Each user has their own upstream token to a third-party system (OAuth access tokens, per-user API keys) and with Supabase Auth those tokens live in a per-user, RLS-protected table keyed to auth.uid(). My approach is a SECURITY DEFINER function that reads the calling user's token and pins it for the life of the query. This lines up with how Supabase already threads per-user context into Postgres. The auth.uid() comes from a session GUC (request.jwt.claims) so resolving a credential from a session variable is the same shape and not a new concept.

-- Tokens live in a per-user, RLS-protected table keyed to auth.uid()
-- SECURITY DEFINER reads the caller's token and pins it for the life of the query
create function set_api_token() returns void
  language sql security definer set search_path = '' as $$
  select set_config('app.api_token',
    (select access_token
       from public.user_integrations
      where user_id = auth.uid()),
    true);
$$;

-- per request:
select set_api_token();
select * from some_foreign_table;

What is the current behavior?

A wasm FDW can only authenticate with a static credential that's fixed when the server is created, either inline in the server options or a Vault secret looked up by id/name. There's no way to hand it a credential that changes per request, per user, or per transaction.

What is the new behavior?

With this PR, stored Supabase Auth credentials can be resolved from a Postgres session variable on each request, so it can match per user/request/transaction. Implemented with two main pieces that are purely additive and backward compatible so an absent or empty setting is a no-op and any static credential configured at the server level still applies.

1. query-setting(name) added to the utils WIT interface (v1 + v2), backed by current_setting(name, true) via SPI. Returns None when the setting is unset.
2. auth_token_setting / auth_token_prefix server options on the OpenAPI FDW. When auth_token_setting is set, the FDW reads that session variable per request and uses it as the Authorization token.

Design note

As shipped, the query-setting function could read any Postgres session setting, not just an auth token, but the auth option is the only setting being read. I could have made it smaller and more focused as auth-only, but I went general because it's a simple tool other FDWs could reuse and other session settings aren't typically sensitive. Could be tightened to read auth only if preferred.

Additional context

Alternatives considered

Approach	Notes
Static server option / Vault secret (today)	Vault resolves the secret once, not per query against session state, so it can't vary per user.
Token as a query qual (hidden column or WHERE token = ...), handled entirely in the guest	Doesn't need an interface change, but the token ends up in the SQL statement text and can leak into pg_stat_statements, logs, and EXPLAIN. Non-starter for a live credential.
Set per-user Vault secrets and have FDW pick the right one by name	Doesn't avoid the problem. FDW can't tell which user is calling (no auth.uid() inside the sandbox) without a per-query signal and it's a lot of secrets to create and rotate.
Session-GUC host function (what I built)	Optional additive change to utils WIT interface, no-ops when the setting isn't there (static creds untouched), keeps the secret out of the query text since it's a set_config session var and is generic enough (hopefully) that any other wasm FDW could use it.

Testing

• Unit tests for apply_session_token covering the edge cases (empty/whitespace no-op, custom prefix, replacing vs appending the header, overriding a static credential).
• A pg_test (openapi_session_token_injection) that runs the full path against the mock server: with the GUC unset no Authorization header is sent, and after set_config the token arrives prefixed.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR adds support for injecting per-session auth tokens into OpenAPI FDW requests by resolving a Postgres session GUC via a new WASM host utility, and validates the behavior end-to-end with a mock server and tests.

Changes:

• Added query-setting to the WASM utils WIT interface and host implementation.
• Implemented dynamic Authorization header injection in openapi_fdw driven by auth_token_setting / auth_token_prefix.
• Added integration + unit tests and updated the mock server to reflect the received Authorization header.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
wrappers/src/fdw/wasm_fdw/tests.rs	Adds an end-to-end test validating session-token injection behavior.
wrappers/src/fdw/wasm_fdw/host/utils.rs	Exposes query_setting as a WASM host function for both utils interface versions.
wrappers/dockerfiles/wasm/server.py	Adds a /whoami endpoint to echo back the Authorization header for tests.
wasm-wrappers/wit/v1/utils.wit	Extends utils interface with query-setting.
wasm-wrappers/wit/v2/utils.wit	Extends utils interface with query-setting.
wasm-wrappers/fdw/openapi_fdw/src/request.rs	Injects a session-resolved Authorization header at request time.
wasm-wrappers/fdw/openapi_fdw/src/config_tests.rs	Adds unit tests for session-token header injection logic.
wasm-wrappers/fdw/openapi_fdw/src/config.rs	Adds auth token config fields and apply_session_token helper.
supabase-wrappers/src/utils.rs	Adds query_setting() helper using current_setting(name, true).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codybrom]

Addressed all four Copilot review comments in 5cd7c01:

1. Case-insensitive authorization match: The headers server option isn't normalized, so a static Authorization header could've been duplicated instead of replaced. Switched the lookup to eq_ignore_ascii_case and added a regression test with a capitalized Authorization header.
2. Misleading test name: renamed to test_session_token_prefix_default_empty and reworded the comment so it matches what it asserts.
3. Swallowed SPI error in query_setting: now reports the error before returning None, matching get_vault_secret right above it. I kept the Option return rather than going to Result, since the WIT host function is option<string>. Undefined settings still come back as None via current_setting(name, true) so only unexpected SPI failures will get reported now.
4. Empty/whitespace auth_token_setting: trimmed to None at parse so the request path doesn't fire a current_setting('') lookup and trimmed auth_token_prefix too (to avoid a 'Bearer ' double-space case).