3 Commits

Author	SHA1	Message	Date
Bohan Jiang	86e7de3e41	feat(server/auth): cache auth token lookups in Redis with 10m TTL ... * feat(server/auth): cache PAT lookups in Redis with 60s TTL Personal access tokens used to hit Postgres on every request: a SELECT to resolve token_hash → user_id, plus a fire-and-forget UPDATE of last_used_at. For a CLI / daemon making many requests per second this is wasted DB load — the token is the same and the answer hasn't changed. Add a Redis-backed cache (auth.PATCache) keyed by token hash, TTL 60s: - On cache hit, the auth middleware skips both the SELECT and the last_used_at UPDATE. last_used_at is now refreshed at most once per TTL window per token, not per request. - On cache miss the middleware falls back to today's behavior: query Postgres, populate the cache, async-update last_used_at. - On revoke, the handler invalidates the cache entry so revocation takes effect immediately rather than waiting for the TTL to expire. This required changing RevokePersonalAccessToken from :exec to :one RETURNING token_hash. The cache is nil-safe: when REDIS_URL isn't configured, NewPATCache returns nil and the middleware degrades to today's always-hit-DB behavior. JWT validation is untouched (already DB-free). Tested with REDIS_TEST_URL — same gating pattern the rest of the suite uses for Redis-backed tests. New tests cover nil-safety, set/ get/invalidate, TTL, and the middleware short-circuit on cache hit. * fix(server/auth): clamp PAT cache TTL to token's remaining lifetime GPT-Boy review caught: a PAT expiring in <60s would still be cached for the full PATCacheTTL window, so the token could continue passing auth on cache hit for up to ~60s after its expires_at. The DB query filters expired tokens (revoked = FALSE AND expires_at > now()), but that filter never ran on a cache hit. Make Set take an explicit ttl, and add TTLForExpiry to compute it: - no expires_at → full PATCacheTTL - expires_at far → full PATCacheTTL - expires_at <60s → time until expiry - already expired → 0, Set skips caching (TOCTOU defense between the SELECT and the Set, since the SELECT already filters expired rows) Regression test pins the clamp behavior end-to-end against Redis. * feat(server/auth): cache daemon-token + PAT lookups in DaemonAuth, bump TTL to 10m Daemon /api/daemon/* requests (heartbeat, claim task) hit DaemonAuth which previously did its own GetDaemonTokenByHash on every request and *also* duplicated the PAT lookup on the mul_ fallback — bypassing the cache added in 1cdd674c. Today's daemons authenticate via mul_ PATs (mdt_ minting isn't wired up yet), so the duplicate PAT path is the one that actually matters for hot-path DB load. Three changes: 1. New auth.DaemonTokenCache mirrors PATCache for the mdt_ path (key = mul:auth:daemon:<sha256>, JSON value = {workspace_id, daemon_id}). Forward-looking infrastructure for when daemon tokens get minted; the middleware short-circuits the DB SELECT on cache hit. TTL clamped to the token's expires_at via the shared TTLForExpiry helper. 2. DaemonAuth now also consults PATCache on its mul_ fallback, sharing the same cache as the regular Auth middleware. A daemon making 4 hb/min collapses from 4 GetPersonalAccessTokenByHash + 4 last_used_at writes per minute to ~1 of each per AuthCacheTTL window (~10 minutes). 3. Rename PATCacheTTL → AuthCacheTTL and bump from 60s to 10 minutes. The constant is now shared between PAT and daemon caches; 10m matches the user-requested longer TTL for further DB write reduction. Revoke latency on the happy path is still instant via active invalidation; the worst-case (Redis Del miss / direct-DB revoke) grows from ~60s to ~10m. Tests cover nil-safety, set/get/invalidate, TTL, clamped TTL on near- expiry tokens, and the middleware short-circuit for both cache paths (mdt_ via DaemonTokenCache, mul_ fallback via PATCache). * feat(server/auth): cache PAT lookups on the WebSocket auth path The third place a PAT is resolved — patResolver.ResolveToken used by realtime.HandleWebSocket — was still hitting Postgres on every /ws auth and firing an unconditional last_used_at UPDATE, bypassing the cache added in 1cdd674c. Wire it through the same shared PATCache so revoking a token through any path (Auth middleware, DaemonAuth PAT fallback, or WS auth) hits all three caches with one Invalidate. Also leaves a comment on DeleteDaemonTokensByWorkspaceAndDaemon — the query has no caller today, but a future deregister/rotate flow must remember to call DaemonTokenCache.Invalidate(hash) for each deleted row, otherwise deleted daemon tokens stay valid until TTL.	2026-04-29 17:07:54 +08:00
Bohan Jiang	f628e48775	refactor(server): error-returning ParseUUID to prevent silent data loss ... * refactor(server): make ParseUUID error-returning to prevent silent data loss (MUL-1410) util.ParseUUID previously swallowed errors and returned a zero pgtype.UUID on invalid input. When this zero UUID reached a write query (DELETE/UPDATE), the SQL matched zero rows and the handler returned 2xx success — producing silent data corruption. #1661 (DeleteIssue with identifier-style ID) was the visible symptom; PR #1680 patched that one site, this commit closes the class of bug. Changes: - util.ParseUUID now returns (pgtype.UUID, error). Add util.MustParseUUID for trusted round-trips that should panic on invalid input. - handler/handler.go: parseUUID wrapper now calls MustParseUUID — any unguarded user-input string reaching it surfaces as a recovered panic (chi middleware.Recoverer → 500) instead of silently corrupting data. Add parseUUIDOrBadRequest(w, s, fieldName) for handler entry points. - Convert every Queries.Delete*/Update* call site reachable from raw user input (autopilot, comment, project, skill, skill_file, label, pin, attachment, feedback, issue assignee, daemon runtime, workspace) to validate UUIDs explicitly with parseUUIDOrBadRequest, returning 400 on invalid input. Where a resolved entity.ID is already in scope, write queries now use it directly instead of re-parsing the URL string. - Update getWorkspaceMember + loadIssueForUser to handle invalid UUIDs gracefully (404/400 instead of panic). - Update util/middleware/cmd-level callers (subscriber_listeners, notification_listeners, activity_listeners, scope_authorizer, middleware/workspace) to use the error-returning API. - Add server/internal/util/pgx_test.go covering valid/invalid input and the MustParseUUID panic contract. - Add TestDeleteIssueByIdentifier + TestDeleteIssueRejectsInvalidUUID regression tests in handler_test.go (the original #1661 bug + the invalid-input case). - Document the handler UUID parsing convention in CLAUDE.md so the rule is enforceable in future PR review. * fix(server): address GPT-Boy review of #1748 P1 fixes from PR #1748 review: 1. Migrate remaining request-boundary UUIDs to parseUUIDOrBadRequest so malformed input returns 400 instead of panic/500. Was missing on: - issue.go: workspace_id in CreateIssue/ChildIssueProgress/ListIssues/ SearchIssues/BatchUpdateIssues/BatchDeleteIssues; project_id / parent_issue_id / lead_id / assignee_id / assignee_ids / creator_id filters; batch issue_ids and assignee/parent/project fields in BatchUpdateIssues (skip on bad input via util.ParseUUID, matching the existing per-row continue semantics). - project.go: project id + workspace_id in GetProject/UpdateProject/ DeleteProject; lead_id in CreateProject/UpdateProject; workspace_id in ListProjects + SearchProjects. - handler.go: resolveActor now uses util.ParseUUID for X-Agent-ID / X-Task-ID headers; invalid UUID falls back to "member" (matches pre-existing semantics) instead of panicking. - issue.go: validateAssigneePair returns 400 on invalid workspace_id instead of panicking. 2. Fix issue:deleted WS event payloads to emit uuidToString(issue.ID) instead of the raw URL string. After an identifier-path delete ("MUL-7"), the previous payload would have leaked the identifier to subscribers, leaving stale entries in frontend caches that key by UUID. Updated DeleteIssue (issue.go:1341) and BatchDeleteIssues (issue.go:1641). The slog "issue deleted" log line also now records the resolved UUID so logs match the WS payload. 3. Extend TestDeleteIssueByIdentifier to subscribe to the bus and assert issue:deleted.payload.issue_id is the resolved UUID, not the identifier. * fix(server): validate remaining reviewed UUID inputs * fix(server): validate remaining handler UUID inputs * fix(server): finish request boundary UUID audit * fix(server): validate remaining request body UUIDs * fix(server): validate runtime path UUIDs * fix(server): validate remaining audit UUID inputs --------- Co-authored-by: Eve <eve@multica.ai>	2026-04-28 14:50:28 +08:00
LinYushen	5c9c2f69fd	feat(auth): email verification login and personal access tokens ... * feat(auth): add email verification login flow with 401 auto-redirect Replace the old OAuth-based login with email verification codes: - Backend: send-code / verify-code endpoints, verification_codes table (migration 009), rate limiting, Resend email service - Frontend: two-step login UI (email → 6-digit OTP), auth store with sendCode/verifyCode - SDK: ApiClient gains onUnauthorized callback; 401 responses auto-clear token and redirect to /login - Fix login button staying disabled due to global isLoading state Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(auth): add brute-force protection, redirect loop guard, and expired code cleanup - VerifyCode: increment attempts on wrong code, reject after 5 failed tries (migration 010) - onUnauthorized: skip redirect if already on /login to prevent infinite loops - SendCode: best-effort cleanup of expired verification codes older than 1 hour Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(auth): add master verification code for non-production environments Allow code "888888" to bypass email verification in non-production environments to simplify development and testing workflows. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(auth): add personal access tokens for CLI and API authentication Add full-stack PAT support: users create tokens in Settings, CLI authenticates via `multica auth login`. Server stores SHA-256 hashes only. Auth middleware extended to accept both JWTs and PATs (distinguished by `mul_` prefix). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-26 14:32:30 +08:00