32dfe6874a
The e2e suite had never been run during this audit. It failed 9 of 256; seven of those predated the audit's changes, established by building a stack from a clean HEAD worktree and running the same specs against it rather than guessing. Most were stale assertions rather than product defects: - quota.spec solved for a target limit using the observed uploader count, but the divisor is max(active, estimated_guest_count, 1) and that config seeds at 100 — so every limit it aimed for came out 100x small and every "within quota" upload 413'd. - rate-limit-shared-nat destructured `ticket` from a 429 body and fetched with `ticket=undefined`, turning the 429 under test into an unrelated 401. It also faked a release with no archive on disk, so the mint's pre-check 404'd and the per-day limiter was never reached; it now does a real release and asserts 200 rather than "not 429". - ddos allowed only [200,429] from ten concurrent streams, so it failed on the very defence it exercises: four tickets per session survive and the rest correctly 401. Now asserts exactly four, which a tightened cap or an inverted eviction order would catch. - auth-tampering asserted a throttled IP is refused EVEN with the correct password. That contract was deliberately removed — it let any phone on the venue NAT lock the operator out of their own admin panel, with a circular escape hatch. Inverted, plus a new check that a success does not refill an attacker's bucket. - moderation-ui assumed a ban leaves a comment "stuck on screen"; `list_for_upload` filters banned authors, so it is hidden from everyone including the host. Now pins the pair that matters — the ban hides it, and the host's permanent removal survives an unban — and the UI leg it used to own is restored as a separate test on a reachable comment. The export specs mint with `?kind=` now that a download ticket is bound to one archive, and four of them assert the mint's 404 rather than the download's: with the kind always known, the pre-check refuses up front instead of after charging a daily download for an archive that cannot be served. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
63 lines
2.9 KiB
TypeScript
63 lines
2.9 KiB
TypeScript
/**
|
|
* Regression guard — a locked/released event rejects uploads with the DISTINCT error code
|
|
* `uploads_locked` (not the generic `forbidden`), so the offline upload queue can tell this
|
|
* REVERSIBLE 403 apart from a permanent one (banned / quota). On `uploads_locked` the client
|
|
* KEEPS the queued blob and retries when the host reopens; a permanent 403 purges it. Before
|
|
* this, a photo staged during a lock was purged and lost the moment the host reopened.
|
|
*/
|
|
import { test, expect } from '../../fixtures/test';
|
|
import { uploadRaw } from '../../helpers/upload-client';
|
|
import { readFileSync } from 'node:fs';
|
|
import { join } from 'node:path';
|
|
import { BASE } from '../../helpers/env';
|
|
|
|
const SAMPLE = () => readFileSync(join(process.cwd(), 'fixtures', 'media', 'sample.jpg'));
|
|
|
|
test.describe('Upload — locked event uses a distinct, reversible 403 (audit fix)', () => {
|
|
test('closed event → 403 uploads_locked; reopen → upload succeeds', async ({ host, api }) => {
|
|
// Close the event: uploads are locked for everyone.
|
|
await api.closeEvent(host.jwt);
|
|
|
|
const locked = await uploadRaw(host.jwt, SAMPLE(), {
|
|
filename: 'during-lock.jpg',
|
|
contentType: 'image/jpeg',
|
|
});
|
|
expect(locked.status).toBe(403);
|
|
const lockedBody = await locked.json();
|
|
// The distinct code is what tells the client to KEEP the blob (reversible), not purge it.
|
|
expect(lockedBody.error).toBe('uploads_locked');
|
|
|
|
// Reopen → the same upload now goes through (the queued blob would have survived).
|
|
await api.openEvent(host.jwt);
|
|
const ok = await uploadRaw(host.jwt, SAMPLE(), {
|
|
filename: 'after-reopen.jpg',
|
|
contentType: 'image/jpeg',
|
|
});
|
|
expect(ok.status, 'upload succeeds once the host reopens').toBeLessThan(300);
|
|
});
|
|
|
|
test('released gallery → 403 gallery_released, the PARKING code (not uploads_locked)', async ({
|
|
host,
|
|
}) => {
|
|
// `release ⇒ lock`, so a released gallery satisfies both conditions and the handler's check
|
|
// ORDER decides which code the guest gets. It must be the release one, and the difference is
|
|
// not cosmetic: `uploads_locked` charges a retry attempt and re-pushes the whole photo on the
|
|
// backoff ladder, against an answer that cannot change until a host acts. `gallery_released`
|
|
// parks it — blob kept, nothing re-sent, and the guest is told to ask the hosts to reopen.
|
|
// This asserted `uploads_locked` while the release branch was unreachable dead code.
|
|
const rel = await fetch(`${BASE}/api/v1/host/gallery/release`, {
|
|
method: 'POST',
|
|
headers: { Authorization: `Bearer ${host.jwt}` },
|
|
});
|
|
expect(rel.status).toBe(204);
|
|
|
|
const rejected = await uploadRaw(host.jwt, SAMPLE(), {
|
|
filename: 'after-release.jpg',
|
|
contentType: 'image/jpeg',
|
|
});
|
|
expect(rejected.status).toBe(403);
|
|
const body = await rejected.json();
|
|
expect(body.error).toBe('gallery_released');
|
|
});
|
|
});
|