Commit Graph

7 Commits

Author SHA1 Message Date
5fbba46a3d fix(build): add missing lib/auth/session-server.ts
Coolify build for acb63a2 failed with:
  Module not found: Can't resolve '@/lib/auth/session-server'
in app/api/projects/create/route.ts, app/api/workspaces/route.ts,
and lib/auth/workspace-auth.ts.

The file existed locally but was never committed in any prior
turn, so the previous build still worked (no consumers) and the
new workspaces feature could not. Adding it now unblocks the
deploy.

Made-with: Cursor
2026-04-20 18:11:12 -07:00
acb63a2a5a feat(workspaces): per-account tenancy + AI access keys + Cursor integration
Adds logical multi-tenancy on top of Coolify + Gitea so every Vibn
account gets its own isolated tenant boundary, and exposes that
boundary to AI agents (Cursor, Claude Code, scripts) through
per-workspace bearer tokens.

Schema (additive, idempotent — run /api/admin/migrate once after deploy)
  - vibn_workspaces: slug, name, owner, coolify_project_uuid,
    coolify_team_id (reserved for when Coolify ships POST /teams),
    gitea_org, provision_status
  - vibn_workspace_members: room for multi-user workspaces later
  - vibn_workspace_api_keys: sha256-hashed bearer tokens
  - fs_projects.vibn_workspace_id: nullable FK linking projects
    to their workspace

Provisioning
  - On first sign-in, ensureWorkspaceForUser() inserts the row
    (no network calls — keeps signin fast).
  - On first project create, ensureWorkspaceProvisioned() lazily
    creates a Coolify Project (vibn-ws-{slug}) and a Gitea org
    (vibn-{slug}). Failures are recorded on the row, not thrown,
    and POST /api/workspaces/{slug}/provision retries.

Auth surface
  - lib/auth/workspace-auth.ts: requireWorkspacePrincipal() accepts
    either a NextAuth session or "Authorization: Bearer vibn_sk_...".
    The bearer key is hard-pinned to one workspace — it cannot
    reach any other tenant.
  - mintWorkspaceApiKey / listWorkspaceApiKeys / revokeWorkspaceApiKey

Routes
  - GET    /api/workspaces                         list
  - GET    /api/workspaces/[slug]                  details
  - POST   /api/workspaces/[slug]/provision        retry provisioning
  - GET    /api/workspaces/[slug]/keys             list keys
  - POST   /api/workspaces/[slug]/keys             mint key (token shown once)
  - DELETE /api/workspaces/[slug]/keys/[keyId]     revoke

UI
  - components/workspace/WorkspaceKeysPanel.tsx: identity card,
    keys CRUD with one-time secret reveal, and a "Connect Cursor"
    block with copy/download for:
      .cursor/rules/vibn-workspace.mdc — rule telling the agent
        about the API + workspace IDs + house rules
      ~/.cursor/mcp.json — MCP server registration with key
        embedded (server URL is /api/mcp; HTTP MCP route lands next)
      .env.local — VIBN_API_KEY + smoke-test curl
  - Slotted into existing /[workspace]/settings between Workspace
    and Notifications cards (no other layout changes).

projects/create
  - Resolves the user's workspace (creating + provisioning lazily).
  - Repos go under workspace.gitea_org (falls back to GITEA_ADMIN_USER
    for backwards compat).
  - Coolify services are created inside workspace.coolify_project_uuid
    (renamed {slug}-{appName} to stay unique within the namespace) —
    no more per-Vibn-project Coolify Project sprawl.
  - Stamps vibn_workspace_id on fs_projects.

lib/gitea
  - createOrg, getOrg, addOrgOwner, getUser
  - createRepo now routes /orgs/{owner}/repos when owner != admin

Also includes prior-turn auth hardening that was already in
authOptions.ts (CredentialsProvider for dev-local, isLocalNextAuth
cookie config) bundled in to keep the auth layer in one consistent
state.

.env.example
  - Documents GITEA_API_URL / GITEA_API_TOKEN / GITEA_ADMIN_USER /
    GITEA_WEBHOOK_SECRET and COOLIFY_URL / COOLIFY_API_TOKEN /
    COOLIFY_SERVER_UUID, with the canonical hostnames
    (git.vibnai.com, coolify.vibnai.com).

Post-deploy
  - Run once: curl -X POST https://vibnai.com/api/admin/migrate \\
      -H "x-admin-secret: \$ADMIN_MIGRATE_SECRET"
  - Existing users get a workspace row on next sign-in.
  - Existing fs_projects keep working (legacy gitea owner + their
    own per-project Coolify Projects); new projects use the
    workspace-scoped path.

Not in this commit (follow-ups)
  - Wiring requireWorkspacePrincipal into the rest of /api/projects/*
    so API keys can drive existing routes
  - HTTP MCP server at /api/mcp (the mcp.json snippet already
    points at the right URL — no client re-setup when it lands)
  - Backfill script to assign legacy fs_projects to a workspace

Made-with: Cursor
2026-04-20 17:17:12 -07:00
a893d95387 fix: reliable fs_users upsert on sign-in
ON CONFLICT expression matching was silently failing due to a mismatch
between the query expression and the index definition (::text cast).
Replaced with an explicit SELECT-then-INSERT-or-UPDATE pattern.

Made-with: Cursor
2026-02-27 18:24:47 -08:00
d8ead667d0 fix: create fs_user on sign-in, fix projects fetch
Made-with: Cursor
2026-02-27 12:39:25 -08:00
17056ea00c fix: restore auth fixes — next-auth prisma adapter, serverExternalPackages, prisma db push on start
Made-with: Cursor
2026-02-27 12:30:52 -08:00
e18db985b6 fix: set session cookie on .vibnai.com for subdomain ForwardAuth
Without domain: .vibnai.com the cookie is scoped to vibnai.com only.
Browsers don't send it to theia.vibnai.com, so ForwardAuth sees no
token and redirects to login even when the user is already logged in.

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-18 18:02:06 -08:00
bbb22f1c37 Switch from SuperTokens to NextAuth.js
BREAKING CHANGE: Replace SuperTokens with NextAuth.js

Why:
- SuperTokens had persistent Traefik routing issues
- SSL certificate not issuing correctly
- Complex infrastructure (separate container)
- NextAuth runs in Next.js app (simpler, no separate service)

Changes:
- Install next-auth, @auth/prisma-adapter, prisma
- Create NextAuth API route: app/api/auth/[...nextauth]/route.ts
- Add Prisma schema for NextAuth tables (users, sessions, accounts)
- Update auth page to use NextAuth signIn()
- Remove all SuperTokens code and dependencies
- Keep same Google OAuth (just simpler integration)

Benefits:
- No separate auth service needed
- No Traefik routing issues
- Sessions stored in Montreal PostgreSQL
- Simpler configuration
- Battle-tested, widely used

All authentication data stays in Montreal!

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-17 15:12:21 -08:00