Files
pn-new-crm/tests/integration/portal-auth.test.ts

107 lines
3.6 KiB
TypeScript
Raw Normal View History

test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
/**
* Portal JWT verification - locks in the audience/issuer hardening shipped
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
* in fix(auth): a token without `aud: 'portal'` + `iss: 'pn-crm'` claims
* must NOT verify, even if it's signed with the correct shared secret.
*
* Without these claims the CRM (better-auth) and portal sessions are
* structurally identical, so a portal token could be replayed against any
* `verifyPortalToken` consumer (and vice versa).
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
*
* The post-Wave-11 `verifyPortalToken` also does a DB lookup for the
* portal user's password-change watermark (auth-flow-auditor C1). Mock
* `@/lib/db` so these tests stay unit-pure and don't need a seeded
* portal_users row.
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
*/
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
import { describe, expect, it, vi } from 'vitest';
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
import { SignJWT } from 'jose';
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
const PORTAL_USER_ID = '33333333-3333-3333-3333-333333333333';
vi.mock('@/lib/db', () => ({
db: {
query: {
portalUsers: {
findFirst: vi.fn(async () => ({
// Watermark in the past so iat (≈ now) is later.
passwordChangedAt: new Date(Date.now() - 60_000),
isActive: true,
})),
},
},
},
}));
const { createPortalToken, verifyPortalToken } = await import('@/lib/portal/auth');
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
const SECRET = new TextEncoder().encode(process.env.BETTER_AUTH_SECRET);
const SESSION = {
fix(audit-wave-11): auth-flow hardening (auth-flow-auditor) Address the two CRITICAL items from auth-flow-auditor plus the high-impact M10 open-redirect. **C1 — Password reset doesn't revoke existing sessions** CRM side: Better Auth has a built-in `emailAndPassword.revokeSessionsOnPasswordReset` flag — flip it on. Verified by reading password.mjs in node_modules/better-auth: this calls `internalAdapter.deleteSessions(userId)` after the password update commits. One-line fix, closes the canonical session-bumping gap on the CRM forgot-password flow. Portal side: the portal uses JWT sessions (not DB-side rows) so there's no `deleteSessions` to call. Add a per-user `password_changed_at` watermark column on `portal_users` and have `verifyPortalToken` reject any token whose `iat` predates the watermark. Updated on `resetPassword`, `changePortalPassword`, and `activateAccount` so every password mutation revokes outstanding cookies. Token shape gains a required `portalUserId` claim so the verify step can do the watermark lookup without an email-based join; legacy tokens (pre-Wave-11) lack it and are rejected → forces one re-login per portal user post-deploy (24h max delay since portal tokens already self-expire at 24h). Migration `0058_portal_password_revocation.sql` stamps existing rows to `now()` so no current session is invalidated by the schema change itself. **M10 — Portal login `?next=` open redirect** `portal/login/page.tsx` did `router.replace(next as never)` against unvalidated `searchParams.get('next')`. An attacker could send a victim to `/portal/login?next=https://evil.example` and the post-sign-in redirect would navigate cross-site. Add `safeNextPath()` that requires `/portal/...` prefix and rejects protocol-relative URLs; everything else falls back to `/portal/dashboard`. **Other auth-flow items confirmed resolved by earlier waves:** - H6 resolve-identifier enumeration: endpoint deleted in Wave 1 (replaced with sign-in-by-identifier which keeps the synthetic email behind a server-side proxy) Tests updated: portal-auth integration test mocks `db` so the new DB-watermark lookup in `verifyPortalToken` stays unit-pure. Tests 1315/1315 after `psql ALTER TABLE` to apply migration locally. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-13 12:52:17 +02:00
portalUserId: PORTAL_USER_ID,
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
clientId: '11111111-1111-1111-1111-111111111111',
portId: '22222222-2222-2222-2222-222222222222',
email: 'client@example.com',
};
describe('portal JWT', () => {
it('round-trips a token signed with createPortalToken', async () => {
const token = await createPortalToken(SESSION);
const verified = await verifyPortalToken(token);
expect(verified).toMatchObject(SESSION);
});
it('rejects a token missing the `aud: portal` claim', async () => {
// Issuer present, audience absent - exactly the shape an old (pre-fix)
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
// portal session would have.
const token = await new SignJWT(SESSION as unknown as Record<string, unknown>)
.setProtectedHeader({ alg: 'HS256' })
.setIssuer('pn-crm')
.setExpirationTime('24h')
.setIssuedAt()
.sign(SECRET);
expect(await verifyPortalToken(token)).toBeNull();
});
it('rejects a token missing the `iss: pn-crm` claim', async () => {
const token = await new SignJWT(SESSION as unknown as Record<string, unknown>)
.setProtectedHeader({ alg: 'HS256' })
.setAudience('portal')
.setExpirationTime('24h')
.setIssuedAt()
.sign(SECRET);
expect(await verifyPortalToken(token)).toBeNull();
});
it('rejects a token with the wrong audience (CRM session replay shape)', async () => {
// What a better-auth session token might roughly look like - same secret,
test(audit-fixes): cover the new permission and webhook surfaces Adds integration coverage for the routes / handlers shipped in the preceding audit-fix commits, plus refactors two route files to expose inner handlers from a sibling `handlers.ts` (the pattern used elsewhere in `src/app/api/v1`) so tests can call them without the `withAuth(withPermission(…))` wrapper. New tests (18 cases across 4 files): - `tests/integration/portal-auth.test.ts` (6) — verifyPortalToken rejects tokens missing `aud: 'portal'` or `iss: 'pn-crm'`, with the wrong audience (CRM-session-replay shape) or wrong issuer, plus a round-trip happy path. Locks in the portal-vs-CRM token isolation. - `tests/integration/api/saved-views-ownership.test.ts` (6) — patch and delete handlers return 403 for a different user, 404 for an unknown id or cross-port id, and 200 for the owner. Ownership is enforced at the route layer regardless of the service's internal filtering. - `tests/integration/api/berth-reservations-list.test.ts` (3) — the new global list returns rows for the current port only and honors pagination params. A reservation in a different port never leaks. - `tests/integration/documents-expired-webhook.test.ts` (3) — handleDocumentExpired flips the document to `expired`, also flips the linked interest's `eoiStatus`, writes a `documentEvents` row, and is a no-op (not a throw) when the documensoId is unknown. Refactors: - `src/app/api/v1/saved-views/[id]/route.ts` extracts `patchHandler` / `deleteHandler` (and the shared `assertViewOwner`) into `handlers.ts`. The route file is now a 4-line `withAuth(handler)` wrapper. - `src/app/api/v1/berth-reservations/route.ts` extracts `listHandler` similarly. Tests import directly from `handlers.ts`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 23:17:08 +02:00
// different audience. Must not verify against the portal path.
const token = await new SignJWT(SESSION as unknown as Record<string, unknown>)
.setProtectedHeader({ alg: 'HS256' })
.setAudience('crm')
.setIssuer('pn-crm')
.setExpirationTime('24h')
.setIssuedAt()
.sign(SECRET);
expect(await verifyPortalToken(token)).toBeNull();
});
it('rejects a token with the wrong issuer', async () => {
const token = await new SignJWT(SESSION as unknown as Record<string, unknown>)
.setProtectedHeader({ alg: 'HS256' })
.setAudience('portal')
.setIssuer('attacker')
.setExpirationTime('24h')
.setIssuedAt()
.sign(SECRET);
expect(await verifyPortalToken(token)).toBeNull();
});
it('rejects garbage', async () => {
expect(await verifyPortalToken('not.a.jwt')).toBeNull();
expect(await verifyPortalToken('')).toBeNull();
});
});