@github-actions[bot]9h ago
[cherry-pick] feat(auth): accept dashboard WorkOS access token on v3/v3.1 routes (#10607)
loading diff…
Cherry-pick of #10607 (master 14cd3412) to production.
Master's version lands in the refactored authMiddleware/ split (resolveRequestAuthInfo.ts); production still has the monolithic authMiddleware.ts, so the change is hand-ported there with identical behavior:
getAuthInfoFromDashboardAccessToken — verifies the WorkOS user token via verifyWorkosJwt (JWKS), resolves the user by verified email (DB_ORG_MEMBER_FIND.byEmail), builds TAPIAuthInfo from x-org-id/x-project-id via getMemberInfoForAPIAUth, ts-results style to match the monolith.getAuthInfoFromRequest ahead of the bearer/api-key branches; disableCookie routes reject it (CookieAuthNotAllowed), exempt from disableProjectAPIKey / self-hosted API-key restriction like the cookie auth it replaces.HEADERS.X_DASHBOARD_ACCESS_TOKEN, apollo CLAUDE.md row, and the unit tests apply unchanged (test imports ./authMiddleware, which resolves to the monolith here).Tests: auth_middleware_dashboard_token.test.ts 6/6 pass on this branch; existing authMiddleware.test.ts + auth_middleware_bearer_disabled.test.ts 66/66 pass; oxlint 0 errors; tsc errors unchanged vs production baseline (all pre-existing in internal-dashboard pages).
🤖 Generated with Claude Code