Files
pn-new-crm/src/app/api/v1/clients/[id]/portal-user/route.ts
Matt Ciaccio 475b051e29
All checks were successful
Build & Push Docker Images / lint (pull_request) Successful in 1m0s
Build & Push Docker Images / build-and-push (pull_request) Has been skipped
feat(portal): replace magic-link with email/password + admin-initiated activation
The client portal no longer uses passwordless / magic-link sign-in. Each
client now has a `portal_users` row with a scrypt-hashed password,
created by an admin from the client detail page; the admin's invite
mails an activation link that the client uses to set their own password.
Forgot-password is wired through the same token mechanism.

Schema (migration `0009_outgoing_rumiko_fujikawa.sql`):

- `portal_users` — one per client account, separate from the CRM
  `users` table (better-auth) so the auth realms stay isolated. Email
  is globally unique, password is null until activation.
- `portal_auth_tokens` — single-use activation / reset tokens. Stores
  only the SHA-256 hash so a DB compromise never leaks live tokens.

Services:

- `src/lib/portal/passwords.ts` — scrypt hash/verify (no new deps;
  uses node:crypto), token mint+hash helpers.
- `src/lib/services/portal-auth.service.ts` — createPortalUser,
  resendActivation, activateAccount, signIn (timing-safe),
  requestPasswordReset, resetPassword. Auth failures throw the new
  UnauthorizedError (401); enumeration-safe behaviour everywhere.

Routes:

- POST /api/portal/auth/sign-in — sets the existing portal JWT cookie.
- POST /api/portal/auth/forgot-password — always 200.
- POST /api/portal/auth/reset-password — token + new password.
- POST /api/portal/auth/activate — token + initial password.
- POST /api/v1/clients/:id/portal-user — admin invite (and `?action=resend`).
- Removed: /api/portal/auth/request, /api/portal/auth/verify (magic link).

UI:

- /portal/login — replaced email-only magic-link form with email +
  password + "forgot password" link.
- /portal/forgot-password, /portal/reset-password, /portal/activate — new.
- New shared `PasswordSetForm` component used by activate + reset.
- New `PortalInviteButton` rendered on the client detail header.

Email send:

- `createTransporter` now wires SMTP auth when SMTP_USER+SMTP_PASS are
  set (gmail app-password or marina-server creds, configured via env).
- `SMTP_FROM` env var lets the sender address be overridden without
  pinning it to `noreply@${SMTP_HOST}`.

Tests:

- Smoke spec 17 (client-portal) updated to the new flow: 7/7 green.
- Smoke specs 02-crud-spine, 05-invoices, 20-critical-path updated to
  match the post-refactor client + invoice forms (drop companyName,
  use OwnerPicker + billingEmail).
- Vitest 652/652 still green; type-check clean.

Drops the dead `requestMagicLink` from portal.service.ts.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-26 15:34:02 +02:00

60 lines
2.1 KiB
TypeScript

import { NextResponse } from 'next/server';
import { z } from 'zod';
import { withAuth, withPermission } from '@/lib/api/helpers';
import { parseBody } from '@/lib/api/route-helpers';
import { errorResponse } from '@/lib/errors';
import { createPortalUser, resendActivation } from '@/lib/services/portal-auth.service';
import { db } from '@/lib/db';
import { eq } from 'drizzle-orm';
import { portalUsers } from '@/lib/db/schema/portal';
const inviteSchema = z.object({
email: z.string().email(),
name: z.string().min(1).max(200).optional(),
});
/**
* POST /api/v1/clients/:id/portal-user
*
* Admin creates a portal account for a client and triggers the activation
* email. Idempotent in spirit: if a portal user already exists for the
* email, returns 409 — the admin can resend the activation via
* ?action=resend.
*/
export const POST = withAuth(
withPermission('clients', 'edit', async (req, ctx, params) => {
try {
const url = new URL(req.url);
const action = url.searchParams.get('action');
if (action === 'resend') {
// Body is optional in resend mode; the portal user id is the path id
// in this case (not the client id). Looking up by client+email so
// admins don't have to track portal-user ids.
const body = await parseBody(req, inviteSchema);
const existing = await db.query.portalUsers.findFirst({
where: eq(portalUsers.email, body.email.toLowerCase().trim()),
});
if (!existing) {
return NextResponse.json({ error: 'Portal user not found' }, { status: 404 });
}
await resendActivation(existing.id, ctx.portId);
return NextResponse.json({ success: true });
}
const body = await parseBody(req, inviteSchema);
const result = await createPortalUser({
clientId: params.id!,
portId: ctx.portId,
email: body.email,
name: body.name,
createdBy: ctx.userId,
});
return NextResponse.json({ data: result }, { status: 201 });
} catch (err) {
return errorResponse(err);
}
}),
);