PR Custody

[STAGING] PLEN-2215 combined audit fixes — 7 apps

@AgentWrapperchecks n/achecks…staging/PLEN-2215-combined-audit-fixes → master7 files · +235 −115updated 1mo ago

▸Description · 1 noise

Summary

Do not merge. This PR aggregates the 7 per-app PRs from the PLEN-2215 audit into a single branch so the changes can be deployed to staging together for end-to-end validation. Each app should still merge to master via its own PR.

Sourced PRs (in merge order)

App	Source PR	Pattern	Change
paychex	#23207	B hard	OAUTH2 → S2S_OAUTH2
gagelist	#23208	A	Add `auth_method: 'body'`
vanta	#23209	B soft	OAUTH2 → S2S_OAUTH2 + scope in token params (bugbot)
anthology_student	#23210	B soft	OAUTH2 → S2S_OAUTH2
pinecone	#23211	B soft	OAUTH2 → S2S_OAUTH2
airship	#23212	B soft	OAUTH2 → S2S_OAUTH2 (region eval, scopes, X-UA-Appkey)
adobe_document_generation_api	#23213	B soft	OAUTH2 → S2S_OAUTH2 + correct IMS host + IMS scopes (bugbot)

Out of scope here

neo4j_s2s_oauth2 is on its own track via #23064 — not bundled in this combined branch (left as-is per the PR owner's direction).
wix and airbyte were deliberately not migrated; see the audit comment for rationale.

Staging test plan

Per app, against staging:

paychex — create auth-config with real Paychex client_id/secret; confirm POST /auth/oauth/v2/token returns 200; hit /companies with the bearer; confirm 200.
gagelist — create auth-config with real client_id/secret; confirm POST /api/token (form-encoded body) returns 200.
vanta — create auth-config; confirm POST /oauth/token with body-form client_id/client_secret/scope returns 200; hit /v1/resources/windows_user_computer.
anthology_student — create auth-config (with institution-specific full baseUrl + creds); confirm POST authorization.campuslabs.com/token returns 200.
pinecone — create auth-config with service-account creds; confirm POST login.pinecone.io/oauth/token (with audience: https://api.pinecone.io/) returns 200; hit /indexes.
airship — test both US (api.asnapius.com region → oauth2.asnapius.com/token) and EU (api.asnapieu.com → oauth2.asnapieu.com/token); confirm Basic auth token exchange returns 200; hit /api/channels with Bearer + X-UA-Appkey.
adobe_document_generation_api — create auth-config with Adobe Developer Console S2S creds; confirm POST ims-na1.adobelogin.com/ims/token/v3 (comma-separated scopes) returns 200; hit /assets with Bearer + X-API-Key.

Notes

Each source PR has its own // ci-skip: config-breaking-changes justification at the top of the file (auth scheme rename for retired Pattern B stubs that could not produce working tokens).
All source PRs are passing CI (validate, checks, lint-and-type-checks).

🤖 Combined branch generated for staging deployment.

▸ 1 bot/status comment hidden

@linear-code[bot]1mo ago

Context

Neo4j Aura's public API (https://api.neo4j.io/oauth/token) only supports the OAuth2 client_credentials grant — there is no redirect authorization_code flow. Today the toolkit declares four auth schemes, two of which target this endpoint:

neo4j_oauth (mode: OAUTH2) — uses OAUTH2 mode but with token_params: { grant_type: 'client_credentials' } and authorization_url === token_url, which is a hack around the missing client_credentials support in OAUTH2.
neo4j_s2s_oauth2 (mode: S2S_OAUTH2) — the correct mode, but currently a stub:
- strictFields: {} → no client_id / client_secret fields are exposed at auth-config creation, so users have no way to provide credentials.
- token_config.auth_method is unset.
- token_config.params: {} → no credentials are sent in the token exchange.

Net effect: the S2S scheme is visible in the UI but cannot actually succeed.

Proposed direction

Flesh out neo4j_s2s_oauth2 in mercury/apps/neo4j/config.ts to match the PayPal S2S pattern (see ComposioHQ/mercury#22415):

Add strictFields.db.client_id and strictFields.db.client_secret with field_type: 'auth_config_field'.
Set token_config.auth_method: 'basic' (Neo4j Aura accepts HTTP Basic).
Set token_config.params: { client_id: fields.client_id, client_secret: fields.client_secret }.

Open questions for planning

Do we deprecate or remove neo4j_oauth? It overlaps with the S2S scheme and the redirect flow isn't real.
Any per-tenant/region URLs for Neo4j Aura that would require the same base_url_host eval-field trick used for PayPal / Zoho Mail?

References

PayPal S2S fix (same pattern, recent):

loading diff…

@linear-code[bot]1mo ago

Context

neo4j_oauth (mode: OAUTH2) — uses OAUTH2 mode but with token_params: { grant_type: 'client_credentials' } and authorization_url === token_url, which is a hack around the missing client_credentials support in OAUTH2.
neo4j_s2s_oauth2 (mode: S2S_OAUTH2) — the correct mode, but currently a stub:
- strictFields: {} → no client_id / client_secret fields are exposed at auth-config creation, so users have no way to provide credentials.
- token_config.auth_method is unset.
- token_config.params: {} → no credentials are sent in the token exchange.

Net effect: the S2S scheme is visible in the UI but cannot actually succeed.

Proposed direction

Flesh out neo4j_s2s_oauth2 in mercury/apps/neo4j/config.ts to match the PayPal S2S pattern (see ComposioHQ/mercury#22415):

Add strictFields.db.client_id and strictFields.db.client_secret with field_type: 'auth_config_field'.
Set token_config.auth_method: 'basic' (Neo4j Aura accepts HTTP Basic).
Set token_config.params: { client_id: fields.client_id, client_secret: fields.client_secret }.

Open questions for planning

Do we deprecate or remove neo4j_oauth? It overlaps with the S2S scheme and the redirect flow isn't real.
Any per-tenant/region URLs for Neo4j Aura that would require the same base_url_host eval-field trick used for PayPal / Zoho Mail?

References

PayPal S2S fix (same pattern, recent):