Files
EventSnap/e2e/specs/04-host/moderation.spec.ts
fabi bbdfae09a0 chore(e2e): add ESLint + Prettier; fix real findings; dedupe BASE
The Playwright suite had no linter and no formatter — only tsc. Add flat-config ESLint
(typescript-eslint, type-aware) and Prettier (2-space, matching the suite's style).

Rules keep the ones that catch real TEST bugs and drop the noise:
  - no-floating-promises KEPT — an un-awaited request/assertion can let a test end before it runs,
    passing vacuously. It caught one: the SSE reader loop in sse-listener is now explicitly `void`.
  - no-unused-vars KEPT — caught three dead bindings (an unused adminToken fixture arg, an unused
    `api` arg, an unused JPEG_MAGIC import), all removed.
  - no-explicit-any OFF — all test code; `any` is the honest type for an untyped res.json() body or
    a page.evaluate() return.
  - no-empty-pattern OFF — Playwright's dependency-free fixtures are `async ({}, use) => {}`.

Refactor: `const BASE = process.env.E2E_FRONTEND_URL ?? '...'` was redeclared verbatim in 23
files — extracted to helpers/env.ts and imported, so a port/scheme change is one edit not a sweep.

Then `prettier --write`. Verified: eslint clean, tsc clean, prettier clean, desktop suite 210
passed / 1 skipped. (One mobile spec flaked once under retries:0 — a pre-existing cross-test
reflow-timing vector from the flakiness audit, not this change: the each-key edit is stable across
16 isolated runs and a clean full mobile re-run.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-15 20:45:59 +02:00

163 lines
6.4 KiB
TypeScript

/**
* USER_JOURNEYS.md §9 — ban / unban / promote / demote. Driven mostly through
* the API because the host dashboard UI changes shape often; integration
* coverage of the buttons lives in a separate UI-focused spec.
*/
import { test, expect } from '../../fixtures/test';
import { seedUpload, seedComment } from '../../helpers/seed';
test.describe('Host — moderation API', () => {
test('ban always hides — a banned user is is_banned AND uploads_hidden (USER_JOURNEYS §9.5)', async ({
api,
host,
guest,
}) => {
// Ban is unconditionally a hide: a banned user's content is "gone" everywhere. The endpoint
// takes no body and there is no per-request opt-out (the legacy hide_uploads flag is gone).
const target = await guest('Banned2');
await api.banUser(host.jwt, target.userId);
const users = await api.listUsers(host.jwt);
const row = users.find((u: any) => u.id === target.userId);
expect(row?.is_banned).toBe(true);
expect(row?.uploads_hidden).toBe(true);
});
test('banned user cannot call /upload', async ({ api, host, guest }) => {
const target = await guest('Banned3');
await api.banUser(host.jwt, target.userId);
// Direct fetch — multipart body shape is just a marker; the auth middleware should reject before parsing.
const res = await fetch(
(process.env.E2E_FRONTEND_URL ?? 'http://localhost:3101') + '/api/v1/upload',
{
method: 'POST',
headers: { Authorization: `Bearer ${target.jwt}` },
body: new FormData(),
}
);
expect(res.status).toBe(403);
});
test('host can promote a guest to host', async ({ api, host, guest }) => {
const target = await guest('Promoted');
await api.setRole(host.jwt, target.userId, 'host');
const users = await api.listUsers(host.jwt);
const row = users.find((u: any) => u.id === target.userId);
expect(row?.role).toBe('host');
});
});
/**
* Regression for the review's H1: role & ban used to be trusted from the JWT and
* never re-checked against the DB, so a demoted/banned host kept full powers for
* the life of their token (up to 30d) and a banned host could even unban
* themselves. The auth extractor now re-reads the live user row, so these take
* effect on the *existing* session with no re-login.
*/
test.describe('Host — live role/ban revocation (H1)', () => {
test('a demoted host loses host powers on their existing session', async ({
api,
adminToken,
guest,
}) => {
const u = await guest('DemoteMidSession');
await api.setRole(adminToken, u.userId, 'host');
// Fresh host token (role is encoded at mint time).
const { body } = await api.recover(u.displayName, u.pin);
const hostJwt = body.jwt;
// Sanity: the token currently has host powers.
await api.listUsers(hostJwt);
// Demote via admin — the host does NOT re-login.
await api.setRole(adminToken, u.userId, 'guest');
// Same token is now rejected with exactly 403 (RequireHost sees the DB role,
// not the JWT claim). Asserting the status guards against a spurious 500
// masquerading as "revoked".
await expect(api.listUsers(hostJwt)).rejects.toThrow(/→ 403/);
});
test('a banned host is locked out immediately on their existing session', async ({
api,
adminToken,
host,
}) => {
// Sanity: host token works.
await api.listUsers(host.jwt);
await api.banUser(adminToken, host.userId);
// Banned users are rejected with 403 by the auth extractor before any handler runs.
await expect(api.listUsers(host.jwt)).rejects.toThrow(/→ 403/);
});
test('a banned host cannot unban themselves', async ({ api, adminToken, host }) => {
await api.banUser(adminToken, host.userId);
await expect(api.unbanUser(host.jwt, host.userId, { expectedStatus: [204] })).rejects.toThrow(
/→ 403/
);
});
// H1 / USER_JOURNEYS §10: a banned user keeps *read* access but every write is
// rejected with 403. The ban is enforced on write handlers + Require{Host,Admin},
// NOT in the base extractor (which would wrongly block reads too).
test('a banned user keeps read access but is blocked from writes', async ({
api,
host,
guest,
db,
}) => {
const base = process.env.E2E_FRONTEND_URL ?? 'http://localhost:3101';
const target = await guest('BannedRW');
const auth = (jwt: string) => ({ Authorization: `Bearer ${jwt}` });
// Seed content the target OWNS *before* the ban, so the delete/edit paths get
// past the ownership check and it's genuinely the ban guard being exercised.
const ownUpload = await seedUpload(target.jwt, { caption: 'mine' });
const ownComment = await seedComment(target.jwt, ownUpload, 'my comment');
await api.banUser(host.jwt, target.userId);
// Reads still succeed.
const read = await fetch(base + '/api/v1/me/context', { headers: auth(target.jwt) });
expect(read.status).toBe(200);
// Every write is rejected — cover ALL guest-reachable mutations, not just
// /upload. delete_upload / delete_comment / edit_upload previously skipped the
// ban guard (a banned owner could still delete/edit their own content).
const create = await fetch(base + '/api/v1/upload', {
method: 'POST',
headers: auth(target.jwt),
body: new FormData(),
});
expect(create.status).toBe(403);
const delUpload = await fetch(base + `/api/v1/upload/${ownUpload}`, {
method: 'DELETE',
headers: auth(target.jwt),
});
expect(delUpload.status).toBe(403);
const editUpload = await fetch(base + `/api/v1/upload/${ownUpload}`, {
method: 'PATCH',
headers: { ...auth(target.jwt), 'Content-Type': 'application/json' },
body: JSON.stringify({ caption: 'edited while banned' }),
});
expect(editUpload.status).toBe(403);
const delComment = await fetch(base + `/api/v1/comment/${ownComment}`, {
method: 'DELETE',
headers: auth(target.jwt),
});
expect(delComment.status).toBe(403);
// The upload survived every blocked write — the delete was rejected, so the row still
// exists (deleted_at IS NULL). We check the DB directly rather than the feed: ban now
// ALWAYS hides, so a banned user's own upload is (correctly) filtered out of every feed
// even though the row is intact. Read access to *other* content is proven by the 200 on
// /me/context above.
expect(await db.countUploadsForUser(target.userId)).toBe(1);
});
});