Adversarial re-review of the persona-audit + audit-followup rounds (6411747..)
found one HIGH and one MED regression plus LOW gaps. All fixed with coverage.
HIGH — export stale-keepsake resurrected by an open_event race
A reopen landing in the window between a *current* export worker's finalize_job
and its ready-flag flip cleared export_released_at + the ready flags but left the
export_job row `done` at the same release_seq. The seq-guarded flip then still
matched and re-set export_{zip,html}_ready=TRUE on a pre-reopen snapshot; the next
re-release read that stale TRUE and skipped regeneration (`if ready { continue }`),
serving a keepsake missing every upload from the reopen window — the exact data
loss migration 012 exists to prevent. Both ready-flip UPDATEs are now additionally
anchored on `export_released_at IS NOT NULL`, so a landed reopen makes the flip a
no-op and the re-release regenerates cleanly.
MED — queue dedup broke for reloaded items
loadQueue rebuilt QueueItems from IndexedDB without copying lastModified, which the
new addToQueue dedup keys on. A file re-selected after a page reload / PWA relaunch
missed the duplicate check and uploaded twice. Rehydration now carries lastModified
(extracted to a pure, tested entryToQueueItem helper).
LOW
- diashow: clear the upload-processed debounce timer in onDestroy (no stray
post-unmount /feed fetch).
- USER_JOURNEYS §9.5: document the reconnect-delta ban replay (hidden_user_ids /
uploads_hidden_at, migration 013), not just the live user-hidden SSE.
- e2e api-client: drop the misleading hide_uploads param from banUser — the backend
takes no body and always hides; strip the dead boolean at all call sites.
Tests
- Extract isReversibleLock (the terminal-403 KEEP-vs-PURGE-blob discriminator) into a
pure exported helper + unit tests, so the data-loss-critical branch is covered
without an XHR harness.
- entryToQueueItem unit tests lock the lastModified-carry regression.
- Document the export flip-race guard in the reopen/re-release spec (the sub-ms
finalize↔flip interleave isn't deterministically forceable with fast fixtures;
covered by the SQL guard + the end-to-end completeness test).
Verified: backend 40 tests, frontend 44 unit tests, svelte-check 0 errors,
e2e 156 passed / 1 skipped on chromium-desktop.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
160 lines
6.7 KiB
TypeScript
160 lines
6.7 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 with hide_uploads=true sets the right flags', async ({ api, host, guest }) => {
|
|
const target = await guest('Banned1');
|
|
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('ban always hides — the hide_uploads flag is ignored (USER_JOURNEYS §10.5)', async ({ api, host, guest }) => {
|
|
// Ban is now unconditionally a hide: even asking NOT to hide still hides, because a
|
|
// banned user's content is "gone" everywhere. The legacy hide_uploads arg is ignored.
|
|
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);
|
|
});
|
|
});
|