4 Commits

Author	SHA1	Message	Date
xarmian	d8b1d98e08	feat(mcp): persistent audit log for /mcp tool calls (TASK-960) (#389) ... * feat(mcp): persistent audit log for /mcp tool calls (TASK-960) Adds a 90-day-retention audit log of every MCP request. Drives the "last used" + "30-day calls" columns the connected-apps page (TASK-954) will read, and gives ops + on-call a forensics surface via a new admin /console/admin/mcp-audit page. Schema deviation from the spec, documented in migration 049: the original task body called for `token_id REFERENCES oauth_tokens(id)` but pad has no `oauth_tokens` table — instead an OAuth grant chain is identified by `request_id` (preserved across refresh-token rotations, see migration 048), and PAT-authenticated MCP requests have no OAuth identity at all. The audit row therefore carries `(token_kind, token_ref)` — `oauth` + request_id for OAuth, or `pat` + api_tokens.id for PATs. The connected-apps page in TASK-954 will filter on token_kind='oauth' to surface third-party connections only. Pieces: - internal/store/migrations/049_mcp_audit.sql + pgmigrations/028 — table. - internal/models/mcp_audit.go — typed entry + 30-day stats DTO. - internal/store/mcp_audit.go — insert / list-by-user / list-by-connection / list-all / per-connection-stats aggregator / 90-day retention sweeper. - internal/server/middleware_mcp_audit.go — async writer + sweeper + middleware that wraps /mcp behind MCPBearerAuth. Hot path is non-blocking enqueue with drop-on-overflow + atomic drop counter. - internal/server/middleware_mcp_auth.go — both PAT + OAuth branches now stash WithMCPTokenIdentity so the audit row attributes correctly. - internal/server/handlers_mcp_audit.go — read endpoints: GET /api/v1/connected-apps/{id}/audit (owner-scoped) + GET /api/v1/admin/mcp-audit (admin-only). - web/src/routes/console/admin/mcp-audit/+page.svelte + tab in admin layout. - Tests cover required-field validation, round-trip, pagination, owner-only filtering, last-used + 30-day aggregates, retention sweep, body-sniff parser, canonical-JSON arg hashing, buffer-full drop path, status-to-result classification, admin gate, DTO field shape. `make check` clean (lint + go test ./... + svelte-kit build). Parent: PLAN-943. * fix(mcp-audit): emit denied row on rate-limit reject per Codex review (round 1) PR #389 round 1 caught: MCPAuditLog is mounted INSIDE MCPBearerAuth, so when bearer auth's per-token rate-limit fires (429) it returns before next.ServeHTTP — and the wrapping audit middleware never sees the response. classifyMCPResult mapped 401/403/429 with no path that could actually reach it. Fix: emitMCPAuditDenied helper called directly from the rate-limit deny branches of both PAT + OAuth paths. Resolved user + token identity are already in scope at that point, so the audit row gets attributed correctly. Pre-auth rejections (no/invalid bearer) stay un-audited because there's no user to attribute them to and the audit_trail table covers those auth-event signals already. Threading: handleMCPPATAuth + handleMCPOAuthAuth now take the entry timestamp so the denied row carries real latency. Test: TestMCPAudit_RateLimited_RecordsDeniedRow drives a real PAT through the rate limiter, drains to 429, and asserts the audit row lands with status="denied" + error_kind="rate_limited" + the right tool_name from the request body.	2026-05-02 22:56:10 -04:00
xarmian	d01bbf6bf1	feat(oauth): live workspace allow-list + role enforcement (TASK-953) (#377) ... Closes the third leg of PLAN-943's OAuth permission model: (token capability tier) × (live workspace role) × (consent allow-list) The first two were already in place — TASK-1027 wired the tier scope check (pad:read / pad:write / pad:admin via tokenScopeAllows) and RequireWorkspaceAccess does the live role lookup. This PR adds the third gate: the workspace-allow-list set at consent time (TASK-952) actually denies workspaces NOT in the user's selection. ## What's new - `oauth.Session.AllowedWorkspaces()` / `SetAllowedWorkspaces()` — typed accessors on session.Extra. Handle BOTH the in-memory []string shape (consent-decide path) AND the JSON-decoded []interface{} shape (post-storage round-trip path). - `WithTokenAllowedWorkspaces` / `TokenAllowedWorkspacesFromContext` — context helpers in internal/server with defensive copies so callers can't corrupt the per-request token state. - `MCPBearerAuth` (OAuth path) reads the token's allow-list from session.Extra and stashes it in context. - `RequireWorkspaceAccess` checks the allow-list against the resolved workspace's slug. Three behaviours match TokenAllowedWorkspacesFromContext's return shapes: - nil → no token-level gate (PAT auth, pre-TASK-952 OAuth tokens). Standard membership applies. - ["*"] → wildcard. Every membership the user has passes. - [slug-a, slug-b, ...] → only listed slugs. Anything else gets 403 permission_denied BEFORE the membership check. ## Live role + revocation Membership revocation takes effect immediately. RequireWorkspaceAccess calls GetWorkspaceMember on every request — if the user lost membership in workspace X, the token's allow-list including X no longer helps; the request is rejected at the standard membership gate. Tested explicitly via TestWorkspaceAllowList_LiveMembershipRevocation. ## Tier × role The natural intersection of tokenScopeAllows (tier-based HTTP-method gate) and per-handler role checks (e.g. requireEditPermission) handles the tier × role table from the PLAN-943 spec: - pad:write tier passes tokenScopeAllows for POST. - But Viewer role fails requireEditPermission's role check. - Net: 403 — tested explicitly via TestWorkspaceAllowList_TierTimesRole_WriteByViewer. ## Tests Unit (no I/O): - TestTokenAllowedWorkspaceMatches — policy table for the helper. - TestWithTokenAllowedWorkspaces_DefensiveCopy + 1 reader counterpart. - TestSession_AllowedWorkspaces_*: setter/getter, nil-clear, defensive copy, JSON round-trip ([]string + []interface{} branches), wildcard JSON round-trip, not-set, nil-session. Integration (full chain, real OAuth flow): - TestWorkspaceAllowList_AllowsListedSlug — listed workspace passes. - TestWorkspaceAllowList_DeniesUnlistedSlug — unlisted gets 403 even though user is owner. - TestWorkspaceAllowList_WildcardAllowsAnyMembership — wildcard passes for every membership. - TestWorkspaceAllowList_LiveMembershipRevocation — token works, then membership revoked, then same token denied. - TestWorkspaceAllowList_PATPathUnaffected — PAT regression: PATs don't carry an allow-list, must NOT hit the gate. - TestWorkspaceAllowList_TierTimesRole_WriteByViewer — pad:write tier × Viewer role on POST item → 403.	2026-05-02 14:29:17 -04:00
xarmian	521853e0a1	feat(mcp): mount /mcp Streamable HTTP transport + OAuth discovery (TASK-950) (#369) ... * feat(mcp): mount /mcp Streamable HTTP transport + OAuth discovery (TASK-950) First public cut of pad-cloud as a remote MCP server (PLAN-943). Mounts the Streamable HTTP transport on /mcp, the RFC 9728 protected-resource discovery doc on /.well-known/oauth-protected-resource, and a 501 stub for RFC 8414 auth-server metadata that TASK-951 will fill in. - internal/server/handlers_mcp.go — Server.SetMCPTransport + chi route registration under cloud-mode gate (self-host stays free of MCP overhead unless explicitly opted in). - internal/server/middleware_mcp_auth.go — Bearer auth that produces the spec-shape 401 + WWW-Authenticate (resource_metadata pointer) MCP clients expect, distinct from /api/v1's JSON-only 401 envelope. Reuses the existing PAT (api_tokens) validation path; OAuth-issued tokens layer in via this same middleware in TASK-951. - internal/server/handlers_well_known.go — RFC 9728 discovery doc + RFC 8414 stub. URLs come from PAD_MCP_PUBLIC_URL + PAD_AUTH_SERVER_URL with request-host fallback for local dev. - internal/server/handlers_mcp_test.go — 7 tests covering cloud-off routes-absent, cloud-on-no-transport routes-absent, discovery doc shape, 501 stub, no-token 401+WWW-Authenticate, bad-format-token 401+WWW-Authenticate, and the valid-PAT happy path with user attached to transport context. - cmd/pad/main.go — wires mcpserver.NewServer + HTTPHandlerDispatcher + StreamableHTTPServer in cloud mode, after SetCloudMode. - internal/config — adds PAD_MCP_PUBLIC_URL and PAD_AUTH_SERVER_URL. Resources are intentionally skipped in this v1 — they require an HTTPResourceFetcher equivalent of ExecResourceFetcher and that's a follow-up task. Tools, prompts, instructions, and meta all flow through identically to the stdio surface (verified via spike against mcp-go v0.50.0's StreamableHTTPServer before writing the real PR). * fix(mcp): enforce PAT scopes on /mcp + WWW-Authenticate fallback per Codex review (round 1) Two findings from PR #369 round 1: 1. SECURITY: A PAT with scopes ["read"] could drive write MCP tools. MCPBearerAuth skipped tokenScopeAllows entirely; the dispatcher's synthesized in-process request bypassed TokenAuth's chain-level check (because WithCurrentUser was already set), so a read-scoped token could POST item create / PATCH update / DELETE silently. Fix: stash apiToken.Scopes via server.WithTokenScopes in MCPBearerAuth; re-check per synthesized request in HTTPHandlerDispatcher.executeRequest using the public server.TokenScopeAllows wrapper. Read-scoped tokens can still drive read-only tools (their HTTP method is GET) — only writes are rejected, with a structured permission_denied envelope. 2. DISCOVERY: writeMCPUnauthorized dropped the WWW-Authenticate header when PAD_MCP_PUBLIC_URL was unset. Cloud-mode deploys without that env var mounted /mcp but broke the discovery handshake — fresh MCP clients rely on the header to find /.well-known/oauth-protected- resource. Fix: pass *http.Request through to writeMCPUnauthorized, derive "https://" + r.Host as the fallback (matches handleOAuthProtected- Resource's existing fallback). Tests: - handlers_mcp_test.go: TestMCP_NoToken_FallsBackToHostWhenPublicURLUnset pins the WWW-Authenticate fallback. TestMCP_ReadScopedPAT_StashesScopes- InContext + TestTokenScopeAllows_PublicWrapper pin the scope-stash side. - dispatch_http_test.go: TestHTTPHandlerDispatcher_ScopeEnforcement_* pin the dispatcher-side enforcement (read-on-write rejected, read-on-read allowed, no-scope-context allows-all). - recordingHandler updated to handle nil r.Body so the read-only GET path can be exercised. * fix(mcp): move scope check to buildAuthedRequest so bulk-update can't bypass it per Codex review (round 2) Round 1 enforced scopes in executeRequest, but dispatch_http_project.go's item bulk-update path constructs each per-item PATCH directly via buildAuthedRequest + d.Handler.ServeHTTP, skipping executeRequest. Net result: a PAT with ["read"] scope could still mutate items through bulk-update even after the round-1 fix. Move the scope check from executeRequest into buildAuthedRequest so every synthesized request — main writes, RMW prefetches, bulk-update per-item PATCHes, link-create POSTs, attachment HEADs — passes through the same gate uniformly. The check is dropped from executeRequest to avoid double-checking; buildAuthedRequest is the universal funnel everything calls. Reads (GET/HEAD/OPTIONS) under ["read"] scope still pass — bulk- update's per-item GET prefetch succeeds, the subsequent PATCH fails at request-build time with permission_denied. The bulk operation returns successfully with all-errors recorded per ref (the "no abort on per-item failure" contract is unchanged). Test: TestHTTPHandlerDispatcher_ScopeEnforcement_BulkUpdateBlockedOnReadScope spies on the test handler; asserts the PATCH never reaches it under ["read"] scope and that each per-item entry carries permission_denied.	2026-05-02 09:25:25 -04:00
xarmian	d84f1180a7	feat(mcp): pluggable Dispatcher + HTTPHandlerDispatcher for remote MCP (TASK-965) (#343) ... * feat(mcp): pluggable Dispatcher + HTTPHandlerDispatcher for remote MCP (TASK-965) Architectural prerequisite for PLAN-943's remote MCP at /mcp. The existing ExecDispatcher (PLAN-942) shells out to the pad binary and inherits credentials from ~/.pad/credentials.json — fine for local stdio MCP where the user IS the subprocess owner, but unworkable for a multi-tenant /mcp endpoint where the dispatcher must serve many OAuth-authenticated users from a single process. This PR ships the alternative path: HTTPHandlerDispatcher calls pad-cloud's existing HTTP handler chain in-process, with the requesting user attached via context. Same handlers, same audit / event-bus / webhook plumbing — just no fork(). ## What's in - internal/mcp/dispatch.go: keeps the existing Dispatcher interface (so ExecDispatcher unchanged) and adds a context-keyed WithDispatchInput helper. The registry attaches the original JSON input map to the dispatch context so dispatchers that prefer structured data over reverse-parsed cliArgs can use it. - internal/mcp/registry.go: forwards the merged input (user-supplied values + session workspace + root flags) to the dispatcher via WithDispatchInput. ExecDispatcher ignores it. - internal/mcp/dispatch_http.go (new): HTTPHandlerDispatcher implementation with a routeTable[cmdPath]→RouteMapper mapping. Seed entry: `item create`. Adding more commands is one RouteMapper per cmdPath plus a routeTable insert. - internal/server/context.go (new): exported WithCurrentUser / WithAPITokenAuth / WithTokenWorkspaceID + read-only CurrentUserFromContext / IsAPITokenFromContext. Lets internal/mcp synthesize an authenticated request without reaching the package-private context keys. - internal/server/middleware_csrf.go: extends the existing "Bearer token requests skip CSRF" rule to also honor the ctxIsAPIToken context flag. Same semantic — non-cookie auth means no CSRF risk — but covers the in-process dispatch path where TokenAuth never sets the Authorization header. Safe because ctxIsAPIToken can only be set by trusted in-process code (TokenAuth on the live Bearer path, or server.WithAPITokenAuth from the dispatcher). ## What's tested - Unit: - TestHTTPHandlerDispatcher_RoutesItemCreate — full happy path with a recordingHandler asserting method/path/body/user-context. - TestHTTPHandlerDispatcher_UnsupportedToolReturnsErrorResult — tools not yet in the routeTable produce IsError-flagged results rather than panicking. - TestHTTPHandlerDispatcher_NoUserReturnsErrorResult — UserResolver returning nil produces an IsError, never a nil-deref. - TestHTTPHandlerDispatcher_HandlerErrorSurfacesAsToolError — 4xx handler responses come back as IsError MCP results matching ExecDispatcher's `pad <cmd> failed: <stderr>` format. - mapItemCreate validation + parseFieldKVP variants. - Integration: TestHTTPHandlerDispatcher_Integration drives the full *server.Server (real chi router, real SQLite store, full middleware chain) with a synthesized OAuth user and asserts the item lands in the DB. ## Scope discipline The DoD called for "dispatch item.create end-to-end" — that's the seed entry. Wiring the remaining ~70 MCP-exposed commands into routeTable is naturally a follow-up before TASK-950 ships /mcp to real users (captured as a separate task post-merge). Audit-log assertion in the integration test is deferred until TASK-960 (B6b) lands the audit log itself. Parent: PLAN-943. * fix(mcp): roll status/priority/category/parent into fields JSON per Codex review (round 1) Codex caught: mapItemCreate placed status / priority / category / parent at the top level of the JSON body, but handleCreateItem only reads them after unmarshalling the Fields string from the request. As written, MCP-driven `item create` would silently drop those flags — breaking parity with the CLI for almost every realistic call (parent- linked tasks, priority-set items, status-overridden ideas, etc.). Mirrored the CLI's behaviour (cmd/pad/main.go ~L2200): build a fields map from the named flags, overlay the repeatable --field entries on top, JSON-encode into ItemCreate.Fields. The handler's existing schema-validation + parent-resolution path now runs unchanged. Repeatable --field still wins last-write — locked into a new test so it doesn't drift. Also rejects --assign / --role with a clear error rather than silently dropping them. The CLI resolves user-name → user-ID and role-slug → role-ID via additional API calls before posting; replicating that pre-resolution belongs in a follow-up that expands the route table for production use. Failing loudly is better than partial parity. Tests: - TestHTTPHandlerDispatcher_RoutesItemCreate now asserts the status/priority/category/parent values land in fields, not the top level — guards against the regression directly. - TestMapItemCreate_ExplicitFieldOverridesNamedFlag locks the last-write-wins precedence between --status and --field status=... - TestMapItemCreate_RejectsUnsupportedAssignRole asserts the defensive error path for the deferred flags. Parent: PLAN-943. * fix(mcp): persist source=cli for HTTPHandlerDispatcher calls per Codex review (round 2) Codex caught: actorFromRequest derives source from the Authorization header — without one, dispatcher-driven calls would persist source="web" instead of source="cli", regressing dashboard/standup/ audit attribution vs. ExecDispatcher. Same pattern as the round-1 CSRF fix: extend actorFromRequest to also honor the ctxIsAPIToken context flag (which TokenAuth sets on the live Bearer-auth path and HTTPHandlerDispatcher sets via server.WithAPITokenAuth on synthesized requests). Both signals mean "non-cookie authenticated, attribute as CLI/agent traffic". Integration test now asserts source="cli" on the created item, so any future regression of this attribution surfaces immediately. Parent: PLAN-943. * fix(mcp): normalize collection aliases in HTTPHandlerDispatcher per Codex review (round 3) Codex caught: CLI's `item create task ...` works because cmd/pad/main.go's normalizeCollectionSlug maps singular/short forms ("task" → "tasks", "doc" → "docs", etc.) to the canonical slug before posting. HTTPHandlerDispatcher's mapItemCreate skipped that step, so the same documented call shape would 404 through the HTTP transport even though it worked through ExecDispatcher. Extracted the alias map to internal/collections.NormalizeSlug so the two transports stay in lockstep without duplication. cmd/pad/main.go's normalizeCollectionSlug now delegates to it; the in-process dispatcher calls it from mapItemCreate after pulling the collection out of input. TestMapItemCreate_NormalizesCollectionAliases locks every documented alias plus a passthrough case for custom collections. Parent: PLAN-943. * fix(server): WithTokenWorkspaceID actually clears on empty input per Codex review (round 4) Codex caught: the docstring said "Pass an empty string to clear" but the implementation early-returned `ctx` unchanged in that case, leaving any stale ctxTokenWorkspaceID set further up the chain active. Always overwrite so the contract holds: passing "" produces a context where tokenWorkspaceID(r) returns "", same as a never-set context. Parent: PLAN-943.	2026-05-01 11:51:28 -04:00