167 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
fabi	7d0334bf22	Merge branch 'fix/video-thumbnail-seek'	2026-07-30 19:40:27 +02:00
fabi	402215d405	fix(video): extract a real poster frame, and stop claiming one that isn't there ... Both the compression worker and the HTML export ran the same invocation: ffmpeg -i <src> -vframes 1 -ss 00:00:01 -vf scale=… -y <out> `-ss` AFTER `-i` is an output-side seek. Against a clip of a second or less ffmpeg exits 0 and writes nothing, and both call sites gated on the exit status: - the worker wrote `thumbnail_path` and logged "thumbnail generated" for a file that was never created, so GET /upload/{id}/thumbnail 404s in the live feed; - the export listed media/<id>_thumb.jpg in data.json while the ZIP writer skipped the unopenable file, so the keepsake drew a broken image tile. Any clip at or under a second, which phones produce constantly — mis-taps, Live Photos, boomerangs. Not data loss; the .mp4 is in both archives and plays. Every server-side signal stayed green. New `services/video.rs` owns the extraction for both callers, mirroring the imaging.rs precedent (created for the same duplication, and it paid off when the max_alloc fix landed in both workers at once). Three changes in it: - `-ss` before `-i`, an input-side seek. NOT sufficient alone: verified against the production image, seeking to 1s in a 1.000s clip is still past the last frame and still exits 0 with no file. The 0s fallback is what actually fixes this, and 1s is tried first only because an opening frame makes a poor poster. - Verify the artifact, not the exit status. This is the check both sites were missing. - Carry compression.rs's 120s timeout. export.rs had NONE — a hung ffmpeg there would strand the job at `running` and the keepsake would never complete. The worker's call used `?`. Tightening the check without also making a missing poster non-fatal would have been far worse than the bug: every sub-second clip would fail compression, exhaust its retries and be soft-deleted. It now logs a warning and leaves `thumbnail_path` NULL, which FeedListCard, VirtualFeed and LightboxModal already handle. The export now sets `thumb: ""` and skips the manifest entry when there is no poster — and does the same for the IMAGE branch, whose decode failure left the identical dangling reference. No viewer change was needed: +page.svelte already guards `{#if post.media.thumb}` and falls back to a video tile with a play glyph. The comment claiming "viewer handles missing thumbs gracefully" was true about the viewer and false about what the backend sent — the guard never fired because the string was never empty. e2e/specs/06-export/export-video.spec.ts had DOCUMENTED this as intended behaviour ("the fixture clip is <1s, so ffmpeg extracts no thumbnail frame — but exits 0 … that's the intended shape here"). sample.mp4 is exactly 1.000s, so every video test in the suite ran at that boundary and none ever fetched the poster. That comment is now corrected to say what it actually was. Tests: 2 unit; a new sample-5s.mp4 fixture so the ordinary first-seek path is covered at all; video-playback now FETCHES the poster rather than asserting the attribute (the one extra request that nine rounds of green never made); a new spec covering both fixtures plus the mirror that a posterless video still uploads and plays; and a keepsake spec asserting every <img> in the opened viewer resolves — naturalWidth === 0 is exactly the broken-tile case, whatever produced it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 19:40:27 +02:00
fabi	2b313e67e0	Merge branch 'fix/track-e2e-fixtures'	2026-07-30 19:39:59 +02:00
fabi	2551c25436	fix(e2e): track the test fixtures the suite reads ... `.gitignore` carried an unanchored `media/`, commented "Media uploads (mounted volume in production)". Production media lives in the `media_data` Docker volume and never appears in the working tree, so that rule guarded nothing real — but unanchored it matches a directory of that name at ANY depth, and the only one in the repo is `e2e/fixtures/media/`. Its entire practical effect was to keep every E2E fixture untracked. A fresh clone got the specs and none of the images or videos they read, and `.github/workflows/e2e.yml` does a plain `actions/checkout` and generates nothing — so the committed CI job could not have run the upload, video, EXIF, quota, oversized-image or export suites at all. It only ever looked green locally, where the fixtures survive as untracked leftovers from whoever first created them. The `origin` remote is git.mc02.dev rather than GitHub, so those workflows have most likely never executed against this repo, which is consistent with nobody noticing. That also makes this a live blocker for the standing "rotate the token and push" item: the first time CI runs, it fails on ENOENT in a way that looks like a broken suite rather than a missing file. Anchors the pattern to `/media/` and commits the six fixtures (672 KB total). Verified `e2e/fixtures/media` is the ONLY directory the old pattern matched, so nothing else changes visibility. Found while adding `sample-5s.mp4` for the video-poster work: the new fixture would have been invisible to every other machine, which is how the existing ones got here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 19:39:59 +02:00
fabi	d51c6b8c4b	Merge branch 'fix/postgres-password-deploy-trap'	2026-07-30 19:28:34 +02:00
fabi	3bcb7c6a76	fix(deploy): close the POSTGRES_PASSWORD trap that broke a fresh deploy either way ... README step 2 said to set "DOMAIN, JWT_SECRET, ADMIN_PASSWORD_HASH, EVENT_NAME, etc." -- POSTGRES_PASSWORD was not in that list. .env.example said to set it and keep it in sync with DATABASE_URL. The two documents disagreed, and both readings ended badly. Branch A, README verbatim: the stack came up GREEN and healthy on CHANGE_ME_use_a_strong_password -- a database credential published in the public repo. The production secret guard covered JWT_SECRET and ADMIN_PASSWORD_HASH, and nothing anywhere looked at the Postgres password. Branch B, .env.example verbatim: a permanent restart loop, "password authentication failed for user eventsnap". The guard's own design made Branch B near-certain. It stops the APP on the first `docker compose up -d` -- but not the `db` service in that same command, which initialises its data directory and bakes in whatever password was in .env at that moment. POSTGRES_PASSWORD is honoured ONLY at initdb. So the intended recovery -- see the refusal, fix your secrets, boot again -- was exactly the sequence that broke it. Nothing in the error named the cause, and the remedy (`down -v`) is both unguessable and the one command you must never run once real data exists. Three changes, which have to ship together: the guard alone would just move operators out of Branch A and into Branch B. - The guard now rejects a placeholder DATABASE_URL in production (the password rides in that URL, which is what the app actually reads). Branch A can no longer boot. - It reports EVERY unset secret in one message instead of returning on the first. Fixing two secrets used to cost two boot cycles, on a stack where Caddy waits on the unhealthy app throughout, and each avoidable cycle is another chance to reach for -v. - A 28P01 handler in db.rs turns the unguessable failure into a self-explaining one: it names the initdb semantics, gives `down -v` with an explicit "deletes db + media + exports, no undo", and gives the ALTER ROLE alternative for when data already exists. Docs: step 2 now names POSTGRES_PASSWORD and says every secret must be set BEFORE the first up; the troubleshooting block covers the auth-failure loop and both remedies. Also replaces htpasswd (apache2-utils -- not on a stock VPS) with `docker run --rm caddy:2-alpine caddy hash-password`, an image the stack already pulls, in README, .env.example and the guard's own message. Verified the output ($2a$14) against the shipped $2y$12 example. Verified on a real Postgres, not just in tests: Branch A refuses and names DATABASE_URL; all three placeholders report in one boot; a volume initialised with one password and connected to with another prints the diagnostic; an unrelated connect failure (dead port) stays silent. 8 unit tests, including that non-prod ignores all of it so the e2e stack is unaffected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 19:28:34 +02:00
fabi	08d92b7531	fix(audit-7): keepsake viewer integrity, readable archives, quota_tolerance floor ... Seventh round, both defects in the keepsake — the one artifact that leaves the system entirely, and so the one where a green server-side signal carries no information at all. Squashed from 2 commits, original messages preserved below. ──────── fix(export): stop a caption bricking the viewer, and ship readable archives Two defects in the keepsake, both silent server-side and both only visible by extracting the real artifact and trying to use it. 1. A CAPTION COULD BRICK THE VIEWER. The viewer's data is inlined as `<script>window.__EXPORT_DATA__={…}</script>` -- it has to be, since guests open index.html over file:// where fetching a sibling data.json is blocked. The escape was `</` -> `<\/`. Against XSS that holds; I fired `</script><img src=x onerror=…>` through a real Chromium parser and it round-trips inert. It does not stop the caption steering the HTML TOKENIZER. `<!--<script` with no later `-->` drives the parser into script-data-double-escaped state, where the template's own `</script>` only steps back to script-data-escaped instead of closing the element. Everything after it -- including the viewer bundle -- is swallowed as script data. Nothing executes and nothing leaks: `__EXPORT_DATA__` is simply never assigned and the keepsake opens blank. A denial of the deliverable, not an XSS. Reproduced in Chromium before changing anything, and the near-miss is worth recording: `<!--<script>alert(1)</script>-->` comes back CLEAN, because the trailing `-->` returns the parser to script-data state. A probe using the terminated form quietly repairs the thing it is testing for. Fix: escape every `<` as `<`, not just `</`. `<` never appears in JSON structural syntax -- only inside string values -- so a global replace is sound, and one rule covers `</script`, `<!--` and `<script` together. That is the point: the old escape was named for the single case it handled. Only the INLINED copy is escaped; data.json is written separately, in no HTML context, and stays literal. 2. EVERY ENTRY IN BOTH ARCHIVES WAS STORED MODE 0000. `ZipEntryBuilder::new` leaves the external file attribute at zero and async_zip's host compatibility defaults to Unix, so `unzip -Z` showed `?---------` on every line of both Gallery.zip and Memories.zip. Windows Explorer ignores Unix modes, which is why this survived; on Linux and macOS `unzip` faithfully applies what the archive asks for and the guest gets a folder of photos none of which they can open. Unconditional -- every keepsake ever produced, no hostile input required -- and invisible server-side: the export succeeds, the ZIP is well-formed, the job writes `done`, /export/status is green. Found by accident. The browser test for defect 1 failed with ERR_ACCESS_DENIED on file://, which looked exactly like a Playwright sandbox quirk; I twice "worked around" it (fresh context, then a separately launched browser) before checking the extracted files and finding mode 000. The workaround was suppressing a real bug. Both workarounds are gone -- the ordinary `page` fixture loads the archive fine now. Fix: all six ZipEntryBuilder sites route through one `keepsake_entry` helper stamping `S_IFREG | 0644`, so the mode cannot be forgotten at a call site. Tests: 3 unit (no `<` survives; the payload still decodes to the original value, because this is a transport encoding and not a sanitiser; a clean payload is untouched) and 2 e2e that release for real, download the real archives, and check them from outside the app -- one opening index.html over file:// in Chromium and asserting the viewer booted, the captions came back verbatim and nothing executed; one asserting every stored mode and every extracted file is readable. Both assertions verified to FAIL against the pre-fix artifacts. ──────── fix(admin): reject quota_tolerance = 0 instead of silently blocking every upload Zero is inside the documented 0–1 range and catastrophic. The per-user limit is `free_disk * tolerance / active_uploaders`, so a tolerance of 0 makes every limit 0 and refuses EVERY upload -- mid-event, with "Du hast dein Upload-Limit für dieses Event erreicht", an error naming the wrong cause entirely. An admin reaching for an off-switch wants `storage_quota_enabled`; the rejection now says so. Rejecting the value rather than raising the floor. A floor of 0.01 was the obvious fix and it is wrong: very small tolerances are legitimate -- they are how a large disk is throttled down to a sensible per-guest ceiling, and how the quota specs steer it (tolerance = target * active / free lands around 1e-5 on the 174 GB volume this suite runs on). A floor would forbid real configurations, and would have broken the entire storage-quota describe block, to prevent one typo. Verified: those four tests still pass. Tests: the rejection, that the stored value is untouched (validation fully precedes any write), and the mirror -- 0.00001 still round-trips -- so the guard can't quietly become a floor later. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 21:37:39 +02:00
fabi	06bc9ddcb3	refactor(export): share the visibility filter between the row query and the estimate ... `query_uploads` selects the rows the archives are built from; `estimate_export_bytes` sizes them for the disk preflight. They stated the same WHERE clause separately, and the direction of drift matters: an estimate that MISSES rows the archive writes under-reserves, which is precisely the ENOSPC the preflight exists to prevent. The integration test claimed to guard this and cannot. Both sides of `the_estimate_sums_exactly_the_rows_the_archive_will_contain` are `SRC:`-marked hand-copies in tests/common/mod.rs -- neither is production code -- so drift means production moved while both copies sat still, and the test goes on passing. The convention is sound for pinning behaviour; it is structurally incapable of detecting divergence from the thing it copies. So fix it where it can be fixed. One `export_visibility_where!()` fragment, `concat!`-ed into both queries at compile time (still `&'static str`, no allocation), with the `u`/`usr` alias contract stated. Divergence is now impossible by construction rather than watched for. The tests keep their value and lose the overclaim: the docstrings now say they pin WHICH uploads may be counted -- each excluded row in the fixture is excluded by a different predicate, so weakening any one of them still fails here -- and say plainly that they do not detect drift, with a pointer to what does. No behaviour change. The filters were verified identical before the hoist (`u.event_id = $1 AND u.deleted_at IS NULL AND usr.uploads_hidden = FALSE AND usr.is_banned = FALSE`); 99 backend tests still pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:50:04 +02:00
fabi	5f702f2b40	fix(audit-5): export disk preflight, media reclaim, low-disk warning, restore docs ... Fifth round, all storage. The keepsake could not fit on the documented hardware and failed halfway through a multi-GB write, leaving the deliverable stuck; the quota had stopped bounding the disk; and the backup had no restore procedure. Squashed from 6 commits, original messages preserved below. ──────── fix(export): refuse an export that cannot fit, and stop peaking at two generations Nothing in export.rs ever asked whether the keepsake would fit. Both archives write their media `Compression::Stored`, so each is essentially a byte-for-byte second copy of the originals -- Gallery.zip always, and Memories.zip for every video and every image at or under 5 MB. On the documented CX33 (80 GB, all three volumes on one filesystem) the upload quota's fixed point leaves ~40 GB free, and a release spawns BOTH halves concurrently against it. The failure is not "the export failed", it is "the deliverable is stuck": 1. ENOSPC lands partway through a multi-GB write. 2. The epoch has already moved, so the job row is `failed` at the CURRENT generation and readiness (epoch = event.export_epoch AND status = 'done') is false -- GET /export/zip 404s. 3. The last good archive sits on disk, unreferenced and unreachable. 4. POST /host/export/rebuild, the only escape, re-arms the same doomed write. Three changes. Reclaim before building. `prune_stale_export_files` ran only after the new archive was written, renamed and finalised. That reads as durability but buys nothing: the moment `invalidate_and_arm` bumps the epoch the old archive is ALREADY unreachable, so keeping it reserves gigabytes for a download nobody can perform -- and for a takedown it is content someone explicitly asked to have removed. Peak usage is now one generation. Narrower than the post-finalize prune on purpose: final archives only, never a `.tmp` or a `viewer_tmp_` dir, since a superseded worker can still be streaming into those and at build START is far more likely to be alive. Preflight the space. SUM(original_size_bytes) over exactly `query_uploads`' visibility filter, +10% for ZIP overhead, multiplied by the number of armed jobs -- without that multiplier each of the two concurrent halves independently sees "it fits" and together they don't. Runs AFTER claim_job, not before as reported: bailing before the claim leaves the row `pending` with no worker and no error, the spinner-forever state `mark_failed`'s status guard exists to prevent. Fails open when the mount can't be read, exactly as the upload quota does. Show the host the reason. /export/status returned {status, progress_pct} and nothing else, so the host dashboard could only render "fehlgeschlagen" next to the retry button. The message was written to the row and surfaced solely in the ADMIN job list -- a different screen, possibly a different person. It now travels with the status, and only on a failure, so a message left on a since-succeeded row can't appear beside a green "ist bereit". Tests: 10 unit (the u128 clamp caught a real bug in the first draft -- saturating_mul then /100 turns an overflow into a number ~100x too small, the one direction that authorises the write being guarded against; the carried-forward archive must survive its own older epoch in the filename), 4 DB-backed (the estimate is asserted against the row set the archive actually contains, not against a restatement of the WHERE clause, so the two queries cannot drift), 3 e2e over the four-hop plumbing. ──────── fix(maintenance): reclaim the media of deliberately deleted uploads The quota stopped bounding the disk. `soft_delete_in_event` stamps `deleted_at` and refunds `total_upload_bytes`, but nothing ever removed the bytes, and the hourly sweep reached only `compression_status = 'failed'`. Upload 500 MB, delete, quota back to zero, upload another 500 MB. Not an attack -- a guest curating their camera roll, which is what people do. The host then sees guests hitting "Du hast dein Upload-Limit erreicht" while the admin widget shows a disk full of files no upload row points at, and the quota message is actively misleading because the space really is gone, just not to anyone the accounting can name. Two retention windows, because the two deletes mean different things. A compression failure keeps its 14 days: the guest didn't ask for it and may not be able to retake the photo. A deliberate removal gets 24 hours -- 14 days outlives the whole event, so a deliberate delete would never reclaim anything while it mattered, and a day still covers a mis-tap. Wider than reported: ALL FOUR paths are reclaimed, not just the original. Preview, display and thumbnail are each a separate file, none counted in `original_size_bytes`, and nothing ever removed them either. That was invisible while the sweep only saw failed compressions (which produce no derivatives) and becomes three leaked files per upload the moment it reaches a successful one. A row is re-selected until every path is cleared, and the columns are cleared only once every file for that upload is gone -- clearing after a partial success would strand the survivors in exactly the unowned state this drains. `backfill_stale_derivatives` selects on `display_path IS NULL AND preview_path IS NOT NULL`, which is close enough to the post-sweep state to be worth pinning: it is guarded on `deleted_at IS NULL`, so it cannot re-decode an original that is no longer on disk. Covered. Residual, deliberately: within the 24h window the bytes are still spent and still unaccounted, so delete-and-re-upload through an eight-hour event can outrun the sweep. Bounding that means holding the quota until the file is reclaimed rather than refunding at `deleted_at`. The low-disk warning is the net under it. Tests: 6 DB-backed, replacing 3. The one asserting an owner-deleted upload IS reclaimed is the exact inverse of what this file used to assert. ──────── feat(host): warn about low disk before it becomes unrecoverable Storage visibility existed in exactly one place: a passive Speicherauslastung widget on the ADMIN dashboard. A host who isn't the admin had no view of it, and nothing warned anyone. README carried "Low-disk alert (< 10 GB free)" under Planned since v1. Two things make this a safety net rather than a nice-to-have. postgres_data, media_data and exports_data are all Docker named volumes on ONE filesystem, so running out doesn't degrade a subsystem -- Postgres stops being able to write and the whole event goes down. And the keepsake needs room for two gallery-sized archives, which the export preflight can only ever refuse AFTER the release, when the event is over and every remedy is harder. So the threshold is not a fixed number alone. It fires on the 10 GB floor the README always named, OR on "you could not build the keepsake right now" -- the trigger a host can still act on, computed with the same arithmetic the preflight uses. Unknown free space is NOT low: it fails open like the upload quota and the preflight do, because a banner that cries wolf on an unreadable mount is a banner nobody reads. Carried on GET /host/event, which the dashboard already fetches on load and on every reload -- no new endpoint, no new poll. Rendered above everything else including the PIN-reset queue, and it names the consequence (the event, not just the download) rather than only the number. Also fixes the host page's formatBytes, which topped out at MB: 30 GB free would have rendered as "30720.0 MB", and a guest with 2 GB of uploads was already being shown that way in the user list. Tests: 5 unit on the threshold (including that plenty of free space is still low when the keepsake wouldn't fit -- the case a fixed threshold misses entirely), 3 e2e. The e2e drives it through `original_size_bytes` rather than a genuinely full disk: the estimate is pure SQL over that column, so overstating one row moves the accounting without touching a byte on disk. ──────── docs: add a restore procedure, fix the backup cadence, and correct quota_tolerance Four things, all found by the same question: what does an operator standing at the venue actually need? A RESTORE PROCEDURE. There was none anywhere, and a backup you have never restored isn't a backup. Two hazards worth writing down: media must be extracted preserving ownership (the app runs as uid 100 / gid 101, and a root-owned restore makes every upload fail with EACCES surfacing as a generic 500), and the app must be STOPPED first, because migrations run on boot and a live pool will fight the restore. Both the backup and the restore commands were run against the real stack before being written down, which caught two that would have failed: - The plain `pg_dump` did not restore: `psql` aborted on `ERROR: schema "_sqlx_test" already exists`. pg_dump emits no DROPs without --clean --if-exists, so the documented dump could only ever be restored into an empty database. Fixed at the source (the dump is now self-cleaning) and verified end to end: 16 tables back, exit 0. - `--same-owner` does not exist in BusyBox tar, which is what `alpine` ships, so the extract aborted before unpacking anything. `--numeric-owner` plus the explicit chown, verified to land 100:101. BACKUP CADENCE. "Weekly offsite" is the wrong shape when every irreplaceable byte is created in one eight-hour window and nobody can retake a wedding. The backup that matters runs that night, and again after the release so the keepsake is captured. Also: take the DB dump and the media tarball back to back, or you get rows pointing at files the dump doesn't know about. quota_tolerance WAS DOCUMENTED AS SOMETHING IT ISN'T. .env.example called it "fraction of disk that triggers the low-storage warning". It is the multiplier in `floor(free_disk * tolerance / active_uploaders)` -- so an operator who wants "warn me later" and sets 0.95 is actually authorising guests to fill 95% of the disk, moving the fixed point from 43% to ~49% and eating the export headroom. The admin UI labelled it "Toleranz (0-1)" with no explanation at all, which invites exactly that reading; it is now "Speicher-Anteil für Gäste" with the formula in the hint. Wrong docs on a tuning knob are worse than no docs. SIZING. New section with the arithmetic: three volumes on one filesystem, the quota fixed point at tolerance/(1+tolerance), and the fact the 80 GB baseline does not cover the keepsake -- both archives are built concurrently and each is roughly a second copy of every original. Provision ~3x expected media, or give exports its own volume. Also ticks the low-disk alert off the roadmap, since it now exists. ──────── chore: raise the db memory limit and rate-limit social writes Two smaller operational items. POSTGRES 512M -> 1G. DATABASE_MAX_CONNECTIONS is 30 for a ~100-guest event (feed polling + SSE + uploads at once), and 30 backends plus Postgres 16's default shared_buffers leaves very little headroom at 512M. An OOM here doesn't degrade one feature -- every request path touches the database, so it takes the event down. Memory is the cheaper knob than shrinking the pool back and reintroducing the queueing it was raised to fix. .env.example now names the pairing explicitly, the way it already does for COMPRESSION_WORKER_CONCURRENCY. SOCIAL WRITES WERE UNTHROTTLED. toggle_like, add_comment and delete_comment were the only mutating endpoints in the app with no limit at all -- upload, join, recover, export and admin login all carry one. Asymmetric coverage rather than a deliberate decision. Low severity, and honestly so: a like fans an SSE broadcast to every client, but the export regeneration a comment deletion triggers is contained (REGEN_DEBOUNCE 20s, workers born with their epoch, superseded ones inert). So the ceiling is 120/min -- far above anything a real guest produces. This bounds a script, not an enthusiastic double-tapper. ONE bucket across all three actions: separate buckets would let a caller triple the aggregate write rate by alternating between them. Keyed per USER, matching the feed and upload limits -- at a venue every guest is behind one NAT, and an IP key is what made the /join and /feed limits turn guests away in the first place. Migration 020 seeds both keys, and both are wired into the admin allowlist, the config UI and the e2e reseed -- the step two earlier per-area toggles missed, which left switches that existed in code and could never be flipped. Tests: 4 e2e, including that the shared bucket really is shared (the part most likely to be lost in a refactor) and that one guest hitting the ceiling doesn't block another behind the same IP. ──────── fix(e2e): stop the video poster assertion racing the ffmpeg thumbnail Pre-existing, and it fired for real during the full-suite run on a cold stack. The lightbox binds `poster={upload.thumbnail_url ?? undefined}`, so the attribute is absent until compression produces the thumbnail. This test asserted on it immediately after seeding, never waiting for the worker -- unlike the Range test further down the same file, which does poll. Against a warm stack the worker usually wins; against a freshly rebuilt one (`stack:down -v`, cold ffmpeg) it doesn't. That is the worst possible time for a false failure: the first run after a rebuild is exactly when you are trying to establish whether a change broke something. Poll for `compression_status = 'done'` before the poster assertion. The `src` assertion needs no wait and keeps none. Verified with --repeat-each=3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 20:10:54 +02:00
fabi	31faccfdf8	fix(audit-4): refuse undecodable images at admission, stop retrying permanent failures ... Fourth round: reject at the door what the worker can only fail on, and stop retrying errors that cannot succeed — while keeping IoError retryable so ENOSPC still gets another attempt. Squashed from 2 commits, original messages preserved below. ──────── fix(upload): refuse undecodable images at the door, and stop retrying them Two halves of the same complaint: an oversized photo was accepted with a 201 and then silently soft-deleted minutes later, after the worker had burned six seconds of backoff re-reaching a conclusion it could not change. Admission. The compression budget now runs at upload time, against the header only, so a guest is told immediately and told why: "Bild hat zu viele Bildpunkte (ca. 99 Megapixel) und kann nicht verarbeitet werden. Bitte verkleinere es und lade es erneut hoch." instead of watching the photo vanish behind a vague "could not be processed" — which arrived only if they happened to still be on the feed with that card loaded. Nothing is stored, so there is no row to soft-delete and no orphan for the sweep to reclaim. Admission and the worker share ONE function (`decoder_within_budget`), so they cannot drift apart and start disagreeing about what is acceptable — a photo accepted at the door and rejected by the worker would be worse than either behaviour alone. The worker keeps its own check: the backfill decodes files that predate this check, and defence in depth is the whole reason the budget exists. Retries. The loop retried every failure, including ones that are a property of the input. An image over the budget, a corrupt file, an unsupported format: each fails identically on all three attempts, so the only effect was 2s + 4s of sleep and three near-identical warnings before the same outcome. `is_permanent_image_error` classifies the `ImageError` variants that cannot change between attempts — Limits, Unsupported, Decoding — and the loop gives up on those at once. `IoError` is deliberately excluded: an ENOSPC while writing a derivative is exactly the transient case the retry exists for, and misclassifying it would turn a blip back into the data loss round 1 fixed. Measured: retry log lines went from 3 per oversized upload to 0. Tests: unit tests for both sides of the classifier (a Limits error is permanent, a missing file is not) and for admission agreeing with the decoder on accept AND reject. The e2e spec is rewritten for the new contract — 400 with an actionable message, nothing stored, backend alive after a burst of four — plus a mirror asserting an ordinary photo still uploads and processes, since a budget that rejected everything would satisfy the other two. ──────── fix(upload): narrow the admission check to the memory budget only The admission check I just added rejected ANY image the decoder couldn't build — corrupt, truncated, or unsupported, not only over-budget. That broke two adversarial tests, and they were right to break. 07-adversarial/file-upload-attacks pins, deliberately, that acceptance follows the MAGIC BYTES: a payload whose first three bytes are a JPEG header is accepted regardless of what follows, because the security property under test is that the client-declared Content-Type has no influence. Both failing cases upload 1024 bytes of JPEG magic followed by zeros. Rejecting those at admission is a different, broader contract than the one asked for, and rewriting an adversarial test to match new behaviour is precisely the thing that needs justifying rather than doing quietly. So admission now checks only what it was meant to: `exceeds_decode_budget` returns true solely for `ImageError::Limits`. A corrupt file goes to the compression worker exactly as before — which handles it gracefully and, since the retry classifier in the previous commit, no longer burns backoff on it. The resource guard is the part that had to move earlier; nothing else did. Tests: the size agreement between admission and the worker is still asserted in both directions, plus a new one writing a magic-bytes-only stub and asserting admission accepts it WHILE the worker still rejects it — pinning the boundary between the two checks so a future widening fails here rather than in the adversarial suite. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 07:55:56 +02:00
fabi	06ade4e158	fix(audit-3): restore the decode allocation guard, route /health in production ... Third round. The decode allocation guard is a regression from round 1: swapping reader.decode() for into_decoder() silently dropped the max_alloc enforcement while keeping the comment that claimed it held. Squashed from 3 commits, original messages preserved below. ──────── fix(imaging): restore the decode allocation guard I removed in round 1 This is a regression I introduced, not a pre-existing gap. Before 05948d8 the compression worker used `ImageReader::decode()`, which does: let mut decoder = Self::make_decoder(format, self.inner, limits.clone())?; limits.reserve(decoder.total_bytes())?; // enforces max_alloc decoder.set_limits(limits)?; Reading the EXIF orientation tag needs `into_decoder()` instead, and that skips the reserve entirely — the crate's own FIXME concedes `from_decoder` doesn't compensate. Nothing else enforces `max_alloc`: the JPEG decoder's `set_limits` only checks support and dimensions. So the 256 MiB budget has been inert since that commit, and round 2 then propagated the weakened path into export.rs through the shared helper, in a commit whose message claimed the helper "carries" the decompression-bomb cap. It didn't, and the comment saying max_alloc "hard-caps the decode allocation" was simply false. What was left was only the per-axis cap, which permits 12000x12000 — 412 MiB decoded, 824 MiB for the two concurrent decodes the worker runs by default, against a 1 GiB container. Deploy-blocking right now because bumping DERIVATIVES_REV makes the first boot after a deploy re-decode the entire gallery two at a time: an OOM kill there restarts the container, which re-runs the backfill. A boot loop, on the first deploy of these fixes. Re-add the reserve exactly as `decode()` does it. Per the budget decision it stays at 256 MiB (~89 MP for RGB8, above any mainstream phone's real output); two concurrent decodes now peak at 512 MiB. Oversized images take the graceful path from round 1 — original retained, quota refunded, upload-error toast — and fail after the header parse but BEFORE any pixels are read, so they cost a header read rather than an allocation. Measured peak during a concurrent oversized burst: 3.0 MiB. Test parity is the other half, and the reason this was invisible: the e2e app container had NO memory limit while production is capped at 1 GiB, so a decode that would OOM-kill production simply succeeded in CI. Mirror the 1 GiB cap in docker-compose.test.yml. That is the third divergence of this shape, after WebKit missing from CI and /health existing only in Caddyfile.test. Tests: a fixture that is 568 KiB on disk and 283 MiB decoded (11000x9000 = 99 MP, deliberately UNDER the per-axis cap so the axis check cannot be what rejects it). A unit test asserts the refusal — it fails against the old code, which decoded it into an 11000x9000 buffer — with a companion asserting an ordinary photo still decodes AND still gets its orientation applied, so the guard didn't become a blanket refusal. An e2e test uploads it singly and as a concurrent pair, asserting compression lands in 'failed' and the backend is still serving and still processing afterwards. ──────── fix(deploy): route /health in production, and actually apply Caddyfile changes Two defects in the update procedure I wrote last round, both of which make a successful-looking deploy a lie. 1. The documented health check could never pass. `curl -fsS https://DOMAIN/health` 404s against a perfectly healthy production stack. The backend registers /health on its ROOT router, not under /api/v1, and the production Caddyfile proxies only /api/* and /media/* — so /health fell through to the SvelteKit catch-all, which has no such route and returns its 404 page. With -f, curl exits 22 and the `&& echo` never runs. My own gloss ("Anything other than ok means check the logs") then sent the operator chasing a phantom outage. e2e/Caddyfile.test has carried `reverse_proxy /health app:3000` since it was written — precisely because the catch-all would otherwise swallow it. Production never did. Per the fix-the-gap-not-the-doc call, production gets the same line, and /health joins the no-store matcher so a cached response can't report the last known state instead of the current one. Verified by running the production Caddyfile against the real backend: /health -> 200 "ok", Cache-Control: no-store, with /api/v1/event and / unaffected. 2. The sequence never reloaded Caddy, so a Caddyfile-only change was dropped. `--build` only rebuilds services with a `build:` section, and caddy is a pinned upstream image. Compose decides whether to recreate a container from its config hash, which covers the mount SPECIFICATION but not the mounted file's CONTENTS — so a git pull that changes ./Caddyfile produces no delta, Compose reports `Running`, and Caddy serves its old config indefinitely. Exit code 0 throughout. Round 1's iOS download fix (137c4ee) is exactly this shape: Caddyfile plus four e2e files, so 100% of its production effect is in that one file. Following the README to the letter deployed it, showed both image IDs changing, and left iOS downloads broken. Demonstrated rather than assumed — added a probe header to a Caddyfile, ran the old sequence (`up -d --build`): header absent, change silently dropped. Ran the new step 4 (`up -d --force-recreate caddy`): header served. `--force-recreate` rather than `restart` or `caddy reload` because the bind mount is resolved to an inode at container-create time and git pull replaces the file rather than editing in place, so a restart can re-read the stale content — the exact failure I hit in round 1 when `caddy reload` didn't pick up an edit. Also rewrites the "db and caddy are untouched … so data volumes survive" sentence. I wrote it as reassurance; "caddy is untouched" was the bug. ──────── chore: take the Bash(*) permission change back out of the shared settings `.claude/settings.json` is committed and applies to anyone who clones. Fabi's local `allow: ["Bash(*)"]` plus deny list ended up in it, inside f0d69f1 — a commit about the image decode guard, which has nothing to do with permissions. That was my mistake, twice. The file was already modified when I started the round: my `git status --short` check printed "(clean)" from an unconditional `echo` rather than from the status output, so I read a dirty tree as clean. Then `git add -A` swept it into an unrelated commit, and I reported afterwards that I had left it untouched. Neither the check nor the claim was true. Restores the shared file to its previous three narrow entries. The permission setup itself is preserved, moved to `.claude/settings.local.json`, which `.gitignore:34` covers precisely so per-user permissions stay per-user — the existing 442 entries there are kept alongside it. Not rewriting f0d69f1 to erase this: main is unpushed so it would be safe, but a visible correction is worth more than a tidy history, and a rebase across the merge commits carries more risk than the mistake does. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 07:18:08 +02:00
fabi	b601c062bd	fix(audit-2): video playback, role identity, keepsake EXIF, recover ceiling, WebKit CI ... Second round: the two regressions the first round introduced, the remaining gaps it left, and the CI change that makes the iOS guarantees actually gate a change rather than being asserted. Squashed from 9 commits, original messages preserved below. ──────── docs(deploy): document the update path — `up -d` alone ships nothing The README only ever described a fresh install. There was no update section anywhere, and `--build` appeared nowhere in the docs. That matters because `app` and `frontend` are `build:` services with no published image tag, and Compose has no source-change detection: if an image by that name exists it is reused. So the natural `git pull && docker compose up -d` reports "Container app-1 Running", rebuilds nothing, and exits 0. A deploy that shipped none of the new code is indistinguishable from a successful one — which is how eleven merged fixes can sit in the repo and never reach the box. Verified both halves against a real stack rather than asserting them: with a source change staged, `up -d` left the image ID untouched; `up -d --build` produced a new image ID and a healthy /health. Adds an "Updating an existing deployment" section covering backup-before-migrate, pull, rebuild, health check, and an image-ID comparison to prove a build actually happened. Also spells out the rollback trap: migrations run on boot and are not undone by checking out an older commit, so rolling back code without restoring the snapshot leaves the schema ahead of the binary and the app refusing to start. ──────── fix(video): play the actual video, and answer Range requests Every video in the app was unplayable. Two independent defects, either one sufficient on its own, and nothing in the suite covered either — no test anywhere played media or asserted a `<video>` src. 1. The lightbox handed `<video>` a JPEG. `pickMediaUrl` is mime-agnostic, and compression only ever produces a THUMBNAIL for a video (one `ffmpeg -vframes 1` frame) — no preview, no display. So in the DEFAULT saver mode the element's src resolved to `/api/v1/upload/{id}/thumbnail`, served as `image/jpeg` with `nosniff` so the browser can't even sniff its way out. Chromium reports DEMUXER_ERROR_COULD_NOT_OPEN. Fixed in the lightbox rather than in `pickMediaUrl`: FeedListCard shares that helper and legitimately wants the thumbnail for its `<img>` poster, so a central mime branch would break the feed. This mirrors the rule the diashow already applies ("videos play the original file directly"). Added `preload="none"` so saver-mode guests on cellular still fetch nothing until they press play — there is no smaller video derivative to offer them — plus `playsinline`, without which iOS hijacks playback into fullscreen. 2. `stream_media_file` ignored Range entirely. It took no request headers, so it could not see `Range`; it always returned 200 with the whole body and never sent Accept-Ranges or Content-Range. iOS Safari opens every `<video>` with a `Range: bytes=0-1` probe and abandons the load without a 206 — so video failed on the app's primary platform even in `original` mode, where the src was already correct. Adds single-range support (`bytes=N-`, `bytes=N-M`, `bytes=-S`) with 206 + Content-Range, 416 + `bytes */len` past EOF, and Accept-Ranges advertised on every response. Anything it won't handle — multi-range, non-bytes units, garbage — falls back to a full 200, which RFC 9110 explicitly permits and which is safer than guessing. All four media routes share the helper, so seeking works uniformly. `get_original` now serves `inline` instead of `attachment`. An attachment disposition is hostile to a `<video>` element, and this route is the only source of playable video bytes; it also matches what the UI promises, since the action is labelled "Original anzeigen" — view, not download. `no-store` is deliberately kept so a takedown still revokes access promptly; ranges work fine under it, the client just re-fetches. Tests: 11 unit tests pin the parser (the iOS `bytes=0-1` probe, inclusive ends, suffix ranges, clamping past EOF, 416 vs 200, malformed fallbacks). A new 03-feed/video-playback spec asserts the src is the original and not the thumbnail, that the browser accepts the bytes as media (readyState > 0, no MediaError), that no video bytes are delivered before play, and that Range returns the correct 206 slices and a 416 past EOF — verified on both Chromium and WebKit. The "not downloaded before play" test asserts no *delivered body* rather than no request: WebKit opens a connection for a preload="none" video and immediately aborts it (GET, no Range, status 0, nothing transferred) while Chromium issues nothing at all. The portable guarantee is that no response carrying bytes completes. ──────── fix(auth): bind the role store to the identity, not to the tab The role store I added in the moderation work is a module-level singleton seeded ONCE at import. `goto()` is a client-side navigation, so leaving and re-joining in the same tab re-imports no module and re-runs no onMount — the previous user's role simply stayed resident. Nothing reset it: not join, recover, admin login, "Event verlassen", `clearAuth`, nor the api.ts 401 auto-clear. So a host who left, followed by a guest joining on the same phone, left that guest with `isStaff === true` and a "🚫 Beitrag entfernen" action on other people's photos. The backend 403s the delete, so this was a false affordance rather than a privilege escalation — but `/feed` never fetched `/me/context`, so unlike every other route it never self-corrected either. It survived until a hard reload. The mirror case was equally broken and easier to overlook: a guest who recovered into a host account got NO host affordances. `clearAuth` already had a hook registry for exactly this shape of problem, with a comment explaining it exists to avoid circular imports. Add the missing mirror, `onSetAuth`, fired by both `setAuth` and `setAdminAuth` after the new token is resident, and have the role store register on both sides: clear to null on logout, re-seed from the new token on login. That also gives `syncRoleFromToken` — dead code with zero callers since I introduced it — its intended purpose. Seeding from the claim fixes the reported bug, but the claim is frozen for the token's 30-day life, so a promotion or demotion still wouldn't reach the feed. `/feed` now calls the existing `refreshEventState()` on mount, which fetches `/me/context` and applies both the authoritative role and the lock/release state in one request. The feed is the one route gating a destructive action on the role, so it should not be the only route running on a stale claim. Tests: 04-host/role-identity-reset drives the real flows. The first asserts the host DOES see the action before asserting the newcomer does not — a negative assertion alone would pass against a build that shipped no moderation at all. The second covers the mirror, promoting a guest server-side while their resident token still claims `role: guest`, so a fix that only cleared the role would fail it. ──────── fix(compression): reclaim failed originals instead of leaking them Round 1 stopped the compression worker deleting an upload's original on failure — a transient ENOSPC or a codec panic must never destroy the only copy of a photo a guest cannot retake. But it left `Upload::soft_delete`'s quota refund in place, so the bytes stayed on disk while the uploader was charged nothing for them. That is worse than it first looks. The row is soft-deleted, so the file is invisible and unowned; a guest hitting a reproducible codec failure can accumulate orphans indefinitely at zero personal cost. And `active_uploaders` counts only users with non-deleted uploads, so dropping out of that count RAISES everyone's per-user ceiling — the leak loosens the very quota meant to contain it. Keep the refund: the uploader didn't cause the failure and shouldn't silently lose quota to it. Bound the leak instead, with an hourly sweep alongside the existing session cleanup in `spawn_periodic_tasks`, reclaiming failed originals older than 14 days — comfortably longer than any single event, so an operator investigating a failed upload still has the file. The selection predicate is the entire safety argument, so it is deliberately narrow: `compression_status = 'failed'` AND soft-deleted AND past the window AND `original_path <> ''`. That is exactly the state the give-up path leaves behind, and it cannot reach a live upload, an owner-deleted one, or a failure still inside its recovery window. `original_path` is cleared after a successful reclaim, which makes the sweep idempotent — otherwise a row whose file is already gone is re-selected on every tick forever. The row itself is kept as the audit trail. Tests reproduce the selection verbatim (same pattern as upload_concurrency) and assert it against five near-misses that must survive, both sides of the retention boundary, and the idempotence property. Also fixes two comments in export.rs still claiming "the compression worker hard-deletes an original when its transcode fails" — no longer true, and the defensive handling they justify is now justified by this sweep and by ordinary deletes instead. ──────── fix(export): apply EXIF orientation in the keepsake too Round 1 fixed EXIF orientation in the compression worker, which corrected the live app — feed preview and diashow display. The export worker was missed, and it does not reuse those derivatives: it re-decodes the originals itself with `image::open`, which ignores the orientation tag, then re-encodes to JPEG, which drops the tag — so the viewer has no way to recover it. The damage was oddly shaped, which is exactly why it reads as a viewer bug: Gallery.zip originals correct (byte-copied, EXIF intact) Memories viewer grid thumbnails SIDEWAYS (always) Memories viewer full image >5 MB SIDEWAYS (re-encoded at 2000px) Memories viewer full image ≤5 MB correct (streamed byte-for-byte) So in the keepsake people actually keep, every portrait photo in the grid was on its side, and clicking through silently "fixed" small photos but not large ones. Rather than paste the decoder dance a third time, extract `services::imaging:: decode_oriented` and route both workers through it, so there is exactly one way to turn a file on disk into a DynamicImage. It carries a second invariant that had also drifted: `image::open` applies NO decode limits, so the export path was decoding arbitrary user-supplied images unbounded — the decompression-bomb cap existed only in the compression worker. Both now come as a pair, which is the point of having one function. Not done: switching export to consume the existing `display` derivative. It would fix orientation and drop a redundant full-resolution decode per photo, but it would also replace the pristine ≤5 MB originals in the keepsake with 2048px re-encodes — a real quality regression in the one artefact people keep forever. Test uploads the round-1 fixture (40x20 landscape tagged Orientation=6), runs a real export, pulls the thumbnail out of Memories.zip and asserts it came back portrait — with a sanity check that the source really is stored landscape, so the test can't pass against a pipeline that does nothing. ──────── fix(recover): cap name cycling, and stop bcrypt blocking the runtime Round 1 gave /join a per-IP ceiling and left /recover with only its `recover:{ip}:{name}` bucket. That key is right for the job it was written for — stopping someone who knows a display name (they're listed on the feed) from burning the victim's 3-strike PIN counter and locking them out on repeat. But the name is ATTACKER-CHOSEN, so cycling names mints a fresh 5-attempt bucket every time and the per-IP cost is unbounded. What sits behind that limiter makes it worse than a normal flood: every call runs a cost-12 bcrypt verify, including an UNCONDITIONAL throwaway verify for names that don't exist — added deliberately to close a timing oracle. So an unknown name is the single cheapest way to make the server do ~200ms of hashing. Adds `recover_ip_rate_per_min` (default 30, migration 019), checked BEFORE the per-name bucket so a name generator can't walk past it. 30/min is far above any real recovery attempt while capping a flood. The per-name bucket is untouched and remains the anti-guessing control. The second half matters as much as the first: bcrypt was running inline on the async runtime everywhere. At cost 12 that pins a tokio worker thread for ~200ms, and there is only one per core — so a login flood stalled every other request on the box, including the feed. There was no spawn_blocking anywhere in the auth module, despite SECURITY-BACKLOG claiming bcrypt had been offloaded. Route all of it through `verify_password` / `hash_password` on the blocking pool. That covers /recover, /admin/login, the host PIN reset, and — the one most likely to bite at a real event — the PIN hash minted on every single /join. Saturating the blocking pool degrades logins; saturating the worker threads degrades everything. Tests: cycling distinct names from one IP now hits the ceiling with a Retry-After, and — the assertion that keeps the fix honest — repeated wrong PINs against ONE name are still throttled with the ceiling set generously high, so the ceiling added protection rather than replacing it. ──────── ci(e2e): run WebKit, so the iOS guarantees actually gate a PR The workflow installed only Chromium and ran chromium-desktop + chromium-mobile. iOS Safari is the app's stated primary user — a wedding guest opening a QR link — and WebKit is the only engine in the matrix that reproduces two of its behaviours: - it enforces X-Frame-Options on the hidden download iframe, so a site-wide DENY makes the keepsake download silently do nothing. Blink hands attachments to the download manager before the frame check and never notices. - it abandons a <video> load unless its Range probe gets a 206. Both of those shipped. Adding 06-export to the webkit project in the round-1 fix bought nothing on a PR, because CI never ran that project at all — the regression test written specifically to catch the blocker only ever executed locally. Runs 71 tests (67 pass, 4 skip on the documented IndexedDB-blob harness limitation) in ~1.5 minutes locally, using the exact command added here. ──────── chore(backend): satisfy cargo fmt `checks.yml` runs `cargo fmt --check`, and it has been failing since the round-1 audit fixes: I gated those on `cargo build` and `cargo clippy` but never ran fmt, so three files drifted then and eight more this round. Pure formatting — no behaviour change; clippy stays at zero and all 70 backend tests still pass. Worth noting for next time: clippy passing is not evidence fmt does. ──────── chore: satisfy prettier in frontend and e2e `checks.yml` runs `npm run format:check` for both projects and both were failing. - frontend/src/lib/ui-store.ts is mine, unformatted since the round-1 upload-queue badge fix — the same miss as the rustfmt one: I gated on svelte-check and eslint but never on format:check. - e2e/loadtest/* and e2e/shots.mjs have been unformatted since 7758270 and are unrelated to the audit work. Fixed here because they block the same gate and the fix is mechanical; no behaviour change in either project. Still red and deliberately NOT fixed here: `npm run lint` in the frontend reports `svelte/prefer-svelte-reactivity` on routes/diashow/+page.svelte:208 (a mutable `Set` where the rule wants `SvelteSet`), pre-existing since 5009590. That one is a real reactivity change in code I have no test coverage for, so it belongs in its own change rather than smuggled into a formatting commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 21:28:11 +02:00
fabi	0c0eed885a	fix(audit-1): media gating, per-user limits, moderation UI, upload integrity ... First audit round: a blocker and eight high-severity findings across the media access gate, the guest-facing rate limiters, host moderation, and the upload pipeline — plus the backup commands and the e2e/production divergences that hid several of them. Squashed from 7 commits, original messages preserved below. ──────── fix(export): let the keepsake download through X-Frame-Options on iOS The keepsake download navigates a hidden, same-origin iframe (deliberately: a top-level navigation to a 404/429 would unload the PWA). Caddy stamped a site-wide `X-Frame-Options: DENY` that also covered the proxied `/api/*`. Blink hands a `Content-Disposition: attachment` response to the download manager at the network layer, so Chromium never noticed. WebKit enforces XFO on the frame navigation first and aborts the load — so on iOS Safari, the app's primary platform, tapping Download did nothing at all, silently. Carve the two export endpoints out to SAMEORIGIN, which still blocks cross-origin framing. Implemented as two disjoint matchers rather than an override: Caddy applies the FIRST `header` directive outermost, so it wins on write and a later, more specific `header` is silently ignored (verified against the running test stack). Also close the test gap that let this ship: - `06-export` ran on chromium-desktop only; add it to `webkit-iphone`, the only engine that enforces XFO on the download frame. - No test in the suite ever clicked a download button — every archive assertion used Node `fetch`, which has no frame and no XFO enforcement. Add a spec that clicks it and awaits a real `download` event. Verified falsifiable: with the blanket DENY reinstated it fails and reports the WebKit refusal as the cause. - Fix `ExportPage`'s card-scoped locators, which matched nothing: the cards carry `class="card p-5"` (a Tailwind `@apply` component class), never the `rounded-xl` the page object looked for. This had left the "shows enabled download buttons" test red on main. ──────── fix(media): close the percent-escape bypass of the media gate `/media/%70reviews/{id}.jpg` served a taken-down photo to anyone, unauthenticated. Verified against the running stack: the literal path 404s, the escaped one returned 200 with the full image. Same for displays, thumbnails and originals, and any escaped byte in any position works. Cause: the block was four `nest_service("/media/previews", 404)` route matches sitting above a `ServeDir` on `/media`. axum matches on the RAW path (matchit does no percent-decoding), while `ServeDir` percent-decodes when it resolves the file. So `%70reviews` missed every blocker, fell through to the ServeDir, and was decoded back to `previews/` on disk — reaching the bytes with no soft-delete and no ban-hide check. That defeats a host takedown, which is the entire point of the gate. Remove the `/media` route tree outright instead of racing the decoder. Nothing needs it: every media URL the backend emits is already a gated `/api/v1/upload/{id}/{original,preview,display,thumbnail}` alias (handlers::feed), the frontend contains zero `/media/` references, and the `/media` in config.rs/disk.rs is the filesystem path while `media/` in export.rs is a path inside the zip. `/media/**` now 404s regardless of encoding. The route's own comment already said it "serves nothing" — it wasn't a backstop, it was the vector. Caddy keeps proxying /media/* deliberately: the app 404s it, and forwarding means the e2e gating specs exercise the app's refusal exactly as production would rather than being masked by the SvelteKit 404 page. Extend the gating spec with the encoded variants — asserting only the literal spelling is what let this sit undetected. ──────── fix(rate-limit): key the guest-facing limiters per user, not per IP At a venue every guest is behind one NAT, so an IP-keyed limiter hands the whole party a single bucket. On a fresh deploy 12 guests arriving together meant 5 joined and 7 were turned away, with no Retry-After telling them when to retry. `/feed` (60/min) and `/export` (3 per DAY — the fourth guest to fetch their keepsake locked out until tomorrow) had the same defect. `feed_delta` was already keyed per-user and its comment states the exact rationale ("so one client can't starve others behind a shared NAT"); this makes its siblings match. - feed:{ip} -> feed:{user_id} (auth was already in scope) - export:{ip} -> export:{user_id} (resolved from the download ticket's session, which was previously looked up and discarded) - join:{ip}: pre-auth, so there is no user to key on. Split in two — a loose per-IP ceiling that only bounds raw volume (new `join_ip_rate_per_min`, default 60, migration 017), plus the real 5/60s anti-spam bucket keyed per (ip, name), mirroring the existing `recover:{ip}:{name}`. admin_login / recover / pin_reset_req stay IP-keyed on purpose and are now commented as such: they guard credential guessing, where a per-user or per-name key would just hand an attacker a fresh bucket per guess. Retry-After: the machinery existed but 7 of 8 sites called `check()` and hard-coded `None`, so a throttled client was told to back off but never for how long. Delete the bool `check()` wrapper entirely so `check_with_retry` is the only entry point and the delay cannot be discarded by accident. Also surface it for the PIN lockout, where the deadline was already known. Fix the "unknown" fallback while here: every client_ip() caller passed that literal, so any request without X-Forwarded-For — anything reaching the app directly rather than through Caddy — shared ONE global bucket. Serve with connect-info and use the peer address. Tests: the reseed forces every limiter toggle off before each test, which is why this whole class was invisible. Add 01-auth/rate-limit-shared-nat, which enables them and asserts 12 guests share an IP without collision, that one guest hammering their own name IS still throttled (so the fix re-keys rather than removes the limit), and that feed/export buckets are per-user. Retarget the ddos join test at the new per-IP ceiling — it asserted the defect. Also seed `admin_login_rate_enabled` (read by the handler, seeded by no migration and no reseed) and register `join_ip_rate_per_min` in the admin config allowlist. Unrelated pre-existing red test fixed: 01-auth/join asserted a "Willkommen!" heading the wedding redesign removed. ──────── feat(moderation): let a host remove a guest's photo or comment from the UI `DELETE /host/upload/{id}` and `DELETE /host/comment/{id}` were complete on the backend — transactional, SSE-broadcasting, audit-logged — and had zero frontend callers. The feed context sheet offered "Löschen" only when `target.user_id === myUserId`, so the only lever a host actually had against an unwanted photo was banning the uploader. That is both disproportionate and ineffective. A ban doesn't retract what was already posted, and it makes things strictly worse for comments: the ban check runs BEFORE the ownership check on the guest delete route, so banning an abusive author leaves their comment on screen and permanently undeletable by them. With no host affordance, nobody could remove it at all. - feed: hosts/admins get "Beitrag entfernen" on other people's posts, routed to the host endpoint (the guest route 403s anything the caller doesn't own) with moderation-specific confirm copy. Own-post "Löschen" is unchanged. - lightbox: same for comments, via /host/comment/{id}. - Ban semantics are deliberately untouched (USER_JOURNEYS §10 — banned users keep read access and cannot write). The deadlock is broken by giving the host a way in, not by loosening the ban. Live role (this had to come first). `getRole()` decodes the JWT claim, but the token is never reissued — the backend slides the session row forward and treats the DB row as authoritative. The claim is therefore frozen for the token's lifetime: up to 30 days. A guest promoted at the party saw no Host-Dashboard and no moderation actions until they signed out and back in, even though `/me/context` had been returning their real role on every page load and 4 of its 6 call sites dropped the field on the floor. Add `role-store.ts`: seeded from the claim so there's no flash of the wrong nav, then corrected by every `/me/context` response. Point the ad-hoc `getRole()` callers at it (account, upload, host, admin, and the new feed gate). The host and admin dashboards now derive `myRole` reactively, so a demotion disables their controls immediately instead of at next login. Tests: 04-host/moderation-ui drives the real UI — host removes a guest photo and it's gone from /feed server-side; a plain guest is offered nothing on someone else's post (the mirror that keeps the first test honest); a promoted guest gains the dashboard on reload while their token still carries `role: guest`; and a host removes the comment of an already-banned guest, asserting first that the author's own delete 403s so the deadlock is real. ──────── fix(upload): stop destroying originals, apply EXIF orientation, surface rejections Three defects in the same pipeline, each of which loses a photo or misrepresents one. 1. A transient error destroyed the guest's only copy. `process`'s error arm unconditionally `remove_file`d the original. Every failure routed there: `create_dir_all`, both derivative `save_with_format` calls (disk full is the canonical case, and it arrives exactly when many guests upload at once), a panic inside the image codec, or a momentary DB-pool exhaustion. The row is only SOFT-deleted, so the bytes were the sole unrecoverable part — and they were the part we deleted. The author already knew this was wrong next door: `backfill_missing_display` says it "must NEVER soft-delete an upload that already has a working preview". Retry up to 3 times with backoff (re-checking the e2e generation guard after each sleep), and on final failure keep the refund + soft-delete but leave the original on disk, logging its path. A failed upload is now recoverable instead of gone. 2. Every portrait photo was stored sideways. Phones don't rotate sensor data — they record the camera orientation in EXIF and store the pixels as shot. `decode()` returns those raw pixels and the JPEG re-encode writes no EXIF, so the 800px preview, the 2048px diashow display and the keepsake were all rotated 90°, while "Original anzeigen" rendered upright because the original keeps its tag. That asymmetry is why it reads as a viewer bug. There was no EXIF handling anywhere in the repo and no exif crate. Read the tag via `into_decoder()` (which carries the decode Limits through, so the decompression-bomb cap is untouched) and apply it. Missing/malformed tags fall back to NoTransforms — most images have none. Existing derivatives are already baked wrong, so migration 018 adds `derivatives_rev` and `backfill_missing_display` becomes `backfill_stale_derivatives`: it now also picks up anything below the current rev and regenerates it once from the original, which still carries its EXIF. Videos are marked current in the migration — ffmpeg already honours the rotation matrix. Bump DERIVATIVES_REV for any future change that invalidates derivatives. 3. A rejected upload vanished without a word. `UploadQueue.svelte` — 162 lines holding the ONLY renderer of an item's error text, the only "Erneut" retry button and the only rate-limit countdown — was never imported anywhere, so `retryItem`, `removeItem` and `clearCompleted` were unreachable at runtime. On a terminal rejection the store purged the blob and wrote a clear German reason into `entry.error` "so the UI shows a clear reason". There was no such UI. And `uploadBadgeCount` counted only pending/uploading, so the badge decremented exactly as if the upload had succeeded. Mount the queue on /upload, toast the reason immediately (the flow sends the user to /feed straight after staging, so the list alone would still miss them), and count blocked/error in the badge so a failure can't read as success. Tests: 02-upload/exif-orientation uploads a 40x20 fixture tagged Orientation=6 and asserts both derivatives come back PORTRAIT, with a sanity check that the source really is stored landscape. 02-upload/rejection-visible bans the uploader between staging and sending, then asserts the toast, the queue row with the server's reason, and that the item is still counted. Note: 02-upload/quota's 4 failures are pre-existing and unrelated — see the next commit. ──────── docs(backup): make the backup commands work; fix the e2e/prod divergences Backup. Both documented commands failed on the shipped stack, and the sentence explaining them was wrong too: - `pg_dump $DATABASE_URL` — `DATABASE_URL` is only ever in the compose environment, never an operator's shell, and it points at `db:5432`, which is compose-internal DNS. The app image has no postgres client either. - `> /media/backups/…` — `/media` is a named volume mounted inside the app container, not a host path, and nothing ever creates a `backups` subdirectory. - `rsync /opt/eventsnap/media/` — that path does not exist anywhere. - "a single path to back up" — false, and dangerously so: exports were moved to their own `exports_data` volume precisely so a keepsake (which contains every photo in the event) can't be served off the media tree. Backing up only `media_data` silently loses every generated keepsake. Rewritten as three commands — db via `docker compose exec -T db pg_dump`, and one `docker run … tar` per volume — all verified against the running stack. The volume mounts use `/src`, not `/media`: I hit the footgun while testing this. Docker pre-populates an EMPTY volume from the image's own directory and chowns it to match, so `-v media_data:/media alpine` tars alpine's cdrom/floppy/usb, writes them into the volume, and leaves it root-owned so the non-root app can no longer write. Mounting where the image has nothing avoids all of it. Documented inline so the next person doesn't rediscover it. Also correct the architecture notes: `/media/*` no longer routes to the backend (that static tree was removed as a gating bypass), and `exports_data` was missing from the volume list — the one volume an operator most needs to know about. e2e stack: add the `EXPORT_PATH` + `/exports` volume it was missing. The file says "mirrors production layout"; without these, exports landed on the container's writable layer at the default path, so export-leak and export-video wrote real archives into ephemeral storage and the "exports live outside media" invariant was never actually exercised. Pre-existing red test, unrelated to the audit: all four 02-upload/quota tests have been failing since 4464147 "stop /me/quota leaking raw disk to guests" (2026-07-19), which post-dates the spec's last edit. `setLimitTo` calibrated `quota_tolerance` from `free_disk_bytes` read through the GUEST's token — a field that commit deliberately zeroes for non-staff. Dividing by it yields a NaN tolerance, so every test in the block died in the helper. Read the calibration inputs through a staff token and keep reading the ceiling back through the guest, whose limit is the thing under test. ──────── test(e2e): document why WebKit can't run the client-queue upload tests Three 02-upload tests have been failing on `webkit-iphone` on main — `02-upload` was already in that project's testMatch, so this is pre-existing red, not something the audit work introduced. Root cause is the harness, not the app. Playwright's Linux WebKit build cannot store Blobs in IndexedDB at all: `put()` fails with "UnknownError: Error preparing Blob/File data to be stored in object store". Confirmed it is not about how Playwright delivers files — a Blob constructed in-page with `new Blob([bytes])` fails identically, while Chromium stores both that and a `setInputFiles` File without complaint. That breaks every test driving the composer (FAB → UploadSheet → /upload → submit), because `handleSubmit` awaits `addToQueue`, which persists the file before it can navigate. The symptom is a submit button stuck on "Wird hochgeladen…" and a timeout waiting for /feed — which reads like an app hang and cost real time to run down. Skip those four (the three above plus the new rejection-visible) on WebKit only, behind a named helper carrying the full explanation, so the next person gets the answer instead of the investigation. Deliberately narrow: WebKit still runs every API-driven upload test, all of 01-auth, 03-feed and 06-export — including the keepsake download, which only WebKit can meaningfully verify. Chromium continues to run all 14. Worth being explicit, since these tests exist to protect iOS: real Safari supports Blobs in IndexedDB, so this is NOT evidence that the offline upload queue is broken on the platform. It does mean that guarantee is currently unverifiable in CI and rests on Chromium coverage plus manual device testing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-28 19:14:37 +02:00
MechaCat02	a77c2ddc00	Merge branch 'fix/prod-readiness-healthcheck-domain'	2026-07-19 18:42:36 +02:00
MechaCat02	40c6fd2ccb	fix(deploy): unblock production bring-up (healthchecks + Caddy DOMAIN) ... Two issues would each stop a clean production `docker compose up` for the event: 1. Healthchecks probed http://localhost:{3000,3001}, but the app and frontend bind IPv4 (0.0.0.0) while `localhost` resolves to ::1 (IPv6) first inside the container — so the probe got "connection refused" and neither container ever turned healthy. Caddy is gated on `condition: service_healthy` for both, so on a fresh boot it would block forever and nothing gets served. Switch both probes to 127.0.0.1. (Verified: both containers now report healthy.) 2. The prod caddy service never received DOMAIN, so the Caddyfile's `{$DOMAIN}` site address expanded to empty — malformed site block, no TLS, no serving. Add `environment: { DOMAIN: ${DOMAIN} }` to the caddy service. Also make .env.example honest and event-ready: - Add DATABASE_MAX_CONNECTIONS (real env lever; recommend 30 for ~100 guests). - The DEFAULT_* upload/rate/capacity vars are NOT read from env — they are seeded into the DB config table and managed at runtime via the admin dashboard. Replace the misleading entries (e.g. upload rate showed 10; live value is 100 via migration 015) with a note pointing to the admin UI and the real seeded defaults. - Document that raising COMPRESSION_WORKER_CONCURRENCY also needs the app memory limit raised (ffmpeg), so a video burst can't OOM the box. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 18:42:32 +02:00
MechaCat02	e69ec4d736	Merge branch 'feat/hide-comments-when-disabled'	2026-07-19 18:27:05 +02:00
MechaCat02	3fb1b5d80d	feat(comments): hide every comment mention when COMMENTS_ENABLED=false ... The kill-switch previously left comment UI/text visible in several places. Sweep the whole surface so a comments-off instance shows no trace: Frontend (main app): - VirtualFeed grid tile: gate the comment button/count on $commentsEnabled (was ungated — the only feed surface still showing it). - admin stats: hide the "Kommentare" count card. - UploadSheet "Uploads geschlossen" notice, host ban-modal description, and host/admin unban confirmations: drop the "…und kommentieren" wording. - export page: drop "Kommentaren" from the keepsake description. Keepsake export (had no concept of the flag): - export.rs: thread comments_enabled into the exported data (ViewerEvent), wired through spawn_export_jobs/recover_exports and their call sites (host.rs, main.rs). - export-viewer: gate comment counts (list + grid) and the lightbox comments section; older exports without the field default to enabled (?? true). Backend still 403s comment writes when disabled (unchanged) — this is the UI half so stale clients and archives match. Verified on the running stack (COMMENTS_ENABLED=false): /event reports comments_enabled=false, a regenerated keepsake embeds "comments_enabled": false with no comment UI, and the uploads-closed notice renders "…ansehen und liken." Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 18:26:59 +02:00
MechaCat02	e1ca9d192f	Merge branch 'feat/diashow-completeness-display'	2026-07-19 17:53:57 +02:00
MechaCat02	5009590882	feat(diashow): guarantee all eligible photos shown + 2048px display derivative ... Diashow completeness rewrite so every eligible upload is shown regardless of bursts, disconnects, or library size: - queue.ts: SlideQueue with live/shuffle queues, allKnown map, recentlyShown ring; merge(dedup, live-first), remove/removeByUser (prunes recentlyShown), knownIds for reconcile-eviction. Adds queue.test.ts (burst/completeness/race). - diashow/+page.svelte: reconcile (full paginate + evict, pre-scan snapshot to spare concurrent uploads) on mount/reconnect/periodic; catchUpNew paginate- until-known for bursts with debounced maxWait; hard-cut removals; decode timeout + candidate fallback + bounded skip so a broken image never stalls. New ~2048px "display" derivative for big-screen sharpness, decoupled from the data-saver preview (800px) used on phones: - migration 016: upload.display_path + v_feed rebuilt (DROP+CREATE, not REPLACE, to slot the column beside preview/thumbnail). - compression: generate_image_derivatives emits preview+display (downscale-only guard, no upscaling); backfill_missing_display regenerates on startup (safe: logs on error, never soft-deletes). - upload.rs/main.rs: GET /upload/{id}/display (mirrors preview auth/cache), /media/displays direct-serve blocked. - feed.rs + types.ts: display_url in feed/delta DTOs. - diashow candidate chain: display -> original -> preview. Verified on the running stack: migration applied, 10/10 existing images backfilled (2048px cap honoured, small images not upscaled), /display serves 200, /feed returns display_url, diashow cycles. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 17:53:53 +02:00
MechaCat02	d9738a4cb9	Merge branch 'fix/prod-env-hardening' ... Harden production env handling: single-quote the bcrypt ADMIN_PASSWORD_HASH so Compose/dotenvy don't corrupt it, and pin MEDIA_PATH to the /media mount.	2026-07-19 16:46:55 +02:00
MechaCat02	669a191968	fix(deploy): harden prod env for bcrypt hash and media path ... Two latent production pitfalls, both proven by probing Compose's env_file resolution: - A bcrypt ADMIN_PASSWORD_HASH is full of $; Compose env_file interpolation AND dotenvy variable substitution both eat the $… segments (as unset vars), corrupting the hash so every admin login 401s. Single-quote it so both read it literally — verified correct for env_file (container) and dotenvy 0.15.7 strong-quote (native). Updated .env.example with the quotes + a warning comment. - MEDIA_PATH: pin it to the /media mount in the app 'environment:' block so a stray host path in .env can't leak in and make every upload 500 with EACCES. environment overrides env_file, so the container is always correct. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 16:46:38 +02:00
MechaCat02	a1733b03d5	Merge branch 'feature/diashow-theming-config' ... Runtime colour theme + COMMENTS_ENABLED switch, diashow transition/fullscreen/wake-lock work, quota disk-leak fix, and docker-compose.dev.yml container-env corrections.	2026-07-19 15:23:04 +02:00
MechaCat02	4026648f98	fix(diashow): working transitions + slide/push, fullscreen, activity controls ... Transitions never actually animated: Svelte scopes @keyframes names but does NOT rewrite animation references in inline style attributes, so the inline 'animation: crossfade-in ...' never matched its scoped keyframe — a hard cut, no fade (Ken Burns' zoom was dead too). Move the animation into scoped classes and pass dynamic values via CSS custom properties. - Real two-layer crossfade: hold the outgoing frame opaque beneath the incoming one (which is decode-gated), so there's no black flash and no decode pop. - New slide transitions (from below/left/right) as one reusable component; the previous frame is pushed off the opposite edge in step (a conveyor/push), easeInOutSine 1s. - Fullscreen toggle button (Fullscreen API) + 'f' shortcut; Esc in fullscreen no longer also navigates away. - Controls now reveal on pointer/keyboard activity and fade when idle (cursor hides too) instead of being always visible. - wakelock: null the sentinel on the OS 'release' event so re-acquire-on-visible actually fires (previously the screen could sleep after the tab was first hidden). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:22:15 +02:00
MechaCat02	44641473ea	fix(quota): stop /me/quota leaking raw disk to guests ... The per-user quota widget was shown to everyone and the /me/quota payload returned free_disk_bytes (raw server free space) and active_uploaders to any authenticated guest. Gate the widget to staff (host/admin) on the upload and account pages, and zero the server-wide telemetry fields for non-staff in the handler. Guests still get their own used/limit so enforcement stays transparent. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:22:03 +02:00
MechaCat02	57a907eca5	feat(theme+comments): runtime colour theme and COMMENTS_ENABLED switch ... Colour theme is configurable at runtime from two seed colours (brand + accent); neutrals stay fixed for contrast safety. Tailwind v4 var()-based tokens let a :root:root override recolour everything with no rebuild; the 50->950 ramps are derived via a color-mix ladder. Config lives in the DB config table (admin UI: Config > Farbschema, presets + custom pickers + live preview), served on the public /event endpoint with env defaults (THEME_PRESET/PRIMARY/ACCENT), propagated live via event-updated SSE, and cached in localStorage for a no-flash boot. The keepsake export mirrors the same ladder in Rust so offline archives match the event theme. COMMENTS_ENABLED (env, default true) is a boot-time kill-switch: the backend rejects new comments with 403 and the frontend hides the comment button (feed card) and panel/composer (lightbox). Existing comments stay in the DB, hidden, and return when re-enabled. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:21:55 +02:00
MechaCat02	6e0a760271	chore(dev): correct container env in docker-compose.dev.yml ... Running in a container picked up host-oriented values from .env via env_file: - MEDIA_PATH pointed at a host path that doesn't exist in the container, so every upload 500'd with EACCES; point it at the /media volume mount. - ADMIN_PASSWORD_HASH lost its $-delimited bcrypt segments to Compose interpolation (admin login 401'd); re-supply it with $$ escaping. - COMMENTS_ENABLED=false to smoke-test the comment kill-switch. NOTE: production compose + .env carry the same MEDIA_PATH / admin-hash pitfalls. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 15:21:44 +02:00
MechaCat02	0abf413693	Merge branch 'test/burst-queue' ... Add an e2e regression covering the client upload queue under a 10-20 photo burst: serial drain, IndexedDB persistence, all-land, and reload-resume.	2026-07-18 19:54:44 +02:00
MechaCat02	002355ba40	test(e2e): client upload-queue under a realistic burst ... Cover the scenario the server-side load test could not — a guest multi-selecting 10-20 photos at once — by driving the real client path (UploadSheet → /upload → addToQueue → processQueue → XHR) rather than hitting POST /upload directly. Two tests assert the properties that keep a guest's photos from being lost: serial per-device draining (one upload in flight at a time), IndexedDB persistence (blobs kept until upload, dropped after), every file landing server-side, and a hard reload mid-burst resuming the rest via loadQueue() with no photo lost. Injects small per-upload latency via route interception so the serial drain is observable and the mid-burst reload window is reliable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 19:54:36 +02:00
MechaCat02	6155b4123d	Merge branch 'release/v0.16.0' ... Wedding redesign, single-file offline keepsake, diashow SSE fix, upload-rate 10→100, and a 100-guest load-test harness.	2026-07-18 17:29:30 +02:00
MechaCat02	7758270cac	chore: shared permission allowlist, screenshot script, gitignore ... Add project .claude/settings.json (read-only cargo check/clippy + git diff allowlist; personal settings.local.json stays gitignored). Add e2e/shots.mjs (one-off mobile screenshot seeder). Ignore load-test run artifacts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:29:20 +02:00
MechaCat02	9b8698f86b	test(loadtest): 100-guest / 1000-image stress harness ... HTTP-level load driver simulating ~100 guests uploading ~1000 images in bursts over a window, plus SSE viewers and one real browser on /diashow. Correlates upload→upload-processed (pipeline latency), waits for the compression backlog to drain against DB ground truth, and emits per-status/latency metrics with pass/fail flags. Includes a realistic-JPEG generator and a diashow-SSE regression check (confirm-diashow-fix.mjs). Run artifacts are gitignored. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:29:20 +02:00
MechaCat02	3c3a7d0082	fix(diashow): open SSE on mount; raise upload rate 10→100/hour ... diashow only subscribed to SSE events but never called connectSse(), so a kiosk/projector opening /diashow directly (not via /feed) never opened the EventSource — the showcase display got a one-time /feed snapshot and no live updates, showing "Noch keine Beiträge" forever when turned on before any photos. Open the stream in onMount (idempotent) and close it in onDestroy, mirroring the feed page. Raise the default upload_rate_per_hour from 10 to 100 (migration 015, scoped to installs still on the old default so admin overrides are preserved). Guests routinely upload bursts of 10-20 photos; the old default throttled the first burst. Also update the code fallback and the test-mode reseed. Both verified end-to-end against the docker test stack. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:29:08 +02:00
MechaCat02	3654aca18b	feat(export): single-file offline keepsake viewer + guest download ... Rebuild the guest "keepsake" (offline HTML gallery) so it renders when the extracted index.html is opened over file://. Browsers block external ES-module scripts and fetch() at origin null, so a normal multi-file SvelteKit build shows a blank window. Build the viewer as one self-contained index.html (inlined JS/CSS via vite-plugin-singlefile, standalone non-SvelteKit entry) and inject the data as window.__EXPORT_DATA__; the backend embeds the built viewer via include_dir! and writes the data global into index.html when zipping. Also surface the guest-facing download: a feed banner and the BottomNav Export tab, both shown once the host releases the export. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:28:54 +02:00
MechaCat02	f243bfe89a	feat(ui): elegant wedding white/silver/gold redesign ... Reskin the whole app via design tokens in tailwind-theme.css (remapped color ramps) plus a define-once component layer in lib/styles/components.css (.btn, .card, .input, .chip, .badge, .sheet, …). Buttons are muted/outlined gold rather than flat fills. Self-host Inter + Fraunces (woff2) under the existing font-src 'self' CSP. Restyle the shared components and the account, admin, host, join, recover and upload screens against the new tokens. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 17:28:42 +02:00
fabi	5546fb82e6	Merge branch 'fix/mobile-flake-ssr-2026-07-16'	2026-07-16 22:02:43 +02:00
fabi	e2b7e54af9	test(e2e): fix load-induced mobile flakes (gesture timing + hydration) ... Three distinct load-induced flakes in the mobile suite, all root-caused from real traces: 1. gestures-longpress "quick tap": longPress() drove page.mouse.down + Node-side waitForTimeout(200) + page.mouse.up — three CDP round-trips. Under load the browser saw the pointerup >500ms after pointerdown, firing the app's real long-press so the ContextSheet opened on a quick tap. New quickTap() helper dispatches pointerdown/up entirely in-browser on one clock, so the earlier-due pointerup always cancels the 500ms timer first — immune to CDP latency. 2/3. upload-cancel-confirm and sheet-escape interacted with server-rendered controls before Svelte hydrated them (caption fill lost -> cancel() navigates to /feed; custom role=radio / leave-button click no-ops). Wait for a post-hydration readiness signal (composer auto-focus / real profile name) before the first interaction — the same barrier the passing feed-based specs already have. (These are now belt-and-suspenders given ssr=false, but keep the specs robust regardless of render mode.) Verified: mobile 22/22, and 0/50 full-mobile runs under load (was ~3/95 pre-fix). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 21:15:26 +02:00
fabi	15d338eeb8	fix(frontend): render client-side (ssr=false) to close pre-hydration interaction races ... EventSnap is a client-only SPA: auth is a localStorage JWT and every page fetches its data in onMount, so SSR only ever produced a logged-out skeleton — including interactive controls that exist in the DOM before hydration attaches their handlers. Interacting in that window silently no-ops: a caption typed on /upload never reaches the reactive state (so cancel() navigates away instead of confirming), and a click on /account's custom role=radio / leave button does nothing. This surfaced as a ~1-4% mobile e2e flake and is a real (if brief) bug for users on slow connections too. Disable SSR app-wide (csr stays on). The server now ships a ~2.5 KB shell with no page controls, so the pre-hydration window is structurally impossible. No SEO is lost (private, QR-gated app). app.html paints a themed boot spinner to cover the JS-load gap (script-free; inline <style> is CSP-safe via style-src 'unsafe-inline'); the root layout's onMount removes it once the app paints. Also fixes the one regression ssr=false exposed: /recover's back chevron used `cameFromApp = from !== null`, which assumes SSR semantics (cold load => from is null). In CSR mode the initial navigation reports a non-null `from`, sending history.back() to about:blank. Key on `type !== 'enter'` instead — SvelteKit's initial-load marker in both SSR and CSR modes. Verified: desktop 210 passed, mobile 22 passed, back-chevron 10/10, frontend gates green (svelte-check 0 errors, eslint, prettier, vitest 46). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 21:15:14 +02:00
fabi	461b1eaf65	Merge branch 'chore/lint-and-format-2026-07-15'	2026-07-15 20:46:00 +02:00
fabi	460258c451	ci: gate ESLint + Prettier for frontend and e2e ... The new linters/formatters only help if they can't be bypassed. checks.yml now runs `npm run lint` and `npm run format:check` for both frontend and e2e, alongside the existing svelte-check / tsc / unit-test gates. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 20:45:59 +02:00
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
fabi	f8cba95e49	chore(frontend): add ESLint + Prettier; fix real findings; format the tree ... The frontend had no JS/TS linter — only svelte-check. Add flat-config ESLint (typescript-eslint + eslint-plugin-svelte) and Prettier (tabs/single-quote, matching the existing style). Rules encode "catch bugs, not enforce taste": - svelte/require-each-key KEPT — it is the exact bug class as the feed mis-tap fix. Fixed every flagged block: keyed activeFilters, filteredUsers, stagedFiles (by previewUrl), captionTags, admin tabs/jobs/users, the export-viewer suggestions/filters/comments, and the static skeleton loops. - svelte/prefer-svelte-reactivity KEPT — inline-disabled only the verified-safe sites (a local freq Map in a $derived.by, throwaway URLSearchParams query builders), with a reason each. - svelte/no-navigation-without-resolve OFF — wants resolve() around every goto()/href; taste, not a bug, and pure churn. - svelte/no-unused-svelte-ignore OFF — those comments are consumed by svelte-check, which ESLint can't see, so it wrongly calls them unused; removing them would reintroduce a11y warnings. - no-explicit-any OFF for *.test.ts only (partial fixtures legitimately use any). Real code fixes beyond keys: removed a dead jobLabel(), an unused ViewerComment import and unused catch binding, an unused scroll-lock arg, and replaced an empty interface with a type alias. Then `prettier --write` (54 files). Formatting only. Verified: eslint clean, svelte-check 0 errors, vitest 46 passed, vite build succeeds. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 20:45:42 +02:00
fabi	4d14df18d0	Merge branch 'chore/rustfmt-2026-07-15'	2026-07-15 19:52:17 +02:00
fabi	ee554e7f38	style(backend): rustfmt the whole tree; gate cargo fmt --check in CI ... The backend had never been run through rustfmt. Doing it in one mechanical pass (134 files) so no future functional diff is buried under formatting churn, then gating `cargo fmt --check` in checks.yml so it stays clean. Formatting only — no logic, SQL, or behaviour changed. Verified after the reformat: cargo test 56 passed, clippy --all-targets -D warnings clean, cargo fmt --check clean. This is the deferred cleanup noted when CI's Format step was first left out. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 19:52:17 +02:00
fabi	0fa40ddf80	Merge branch 'fix/edit-upload-keepsake-and-coverage-2026-07-15'	2026-07-15 19:48:31 +02:00
fabi	c48d43f5b3	test(e2e): cover the untested security lifecycles (PIN reset, logout-all, ban gating, caption) ... Closes the coverage gaps the audit flagged and I verified were real: pin-reset-lifecycle.spec.ts (new): the whole "I forgot my PIN" journey (§4) had only its 403 gate tested. Now: the always-204 non-enumeration contract (unknown name looks identical to known); dedup (ON CONFLICT); admins are EXCLUDED from the queue; the 3-per-15-min throttle; and a host reset REVOKES the target's sessions (the pre-reset JWT 401s afterward) and clears the request. Sessions are validated per-request against the DB, so the revoke is observable. logout-everywhere.spec.ts (new): DELETE /sessions ("sign out everywhere") had ZERO tests. Proves it revokes ALL of the caller's sessions across two devices (both tokens 401 after), not just the current one, and doesn't touch another user's sessions. media-gating: the file claimed delete AND ban-hide both revoke preview access, but only delete was exercised. Add the ban case — a banned uploader's gated preview 404s, same as a takedown. (Thumbnail shares the identical find_by_id_visible gate; the seed fixture produces no thumbnail derivative, so preview is the honest thing to assert.) export caption test: an edit after release regenerates the viewer (epoch bumps) while the ZIP is carried forward, not rebuilt — guards the fix in the previous commit. Helpers: api.listPinResetRequests; db.countSessionsForUser / countPinResetRequestsForUser. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 19:48:31 +02:00
fabi	db7c4459d7	fix(upload): editing a caption after release now regenerates the keepsake ... edit_upload updated the caption/hashtags and nothing else. A caption lives in the HTML viewer keepsake (the ZIP holds media only — export.rs), so after release the downloadable viewer kept showing the OLD caption forever while the live feed showed the new one. Editing stays allowed while locked/released — like comments and likes, the lock freezes new uploads only (USER_JOURNEYS §9.3) — so the fix is to regenerate, not forbid: the edit and an invalidate_and_arm(ViewerOnly) share one transaction (same atomicity as delete_upload), then start_regen after commit. ViewerOnly carries the finished ZIP forward untouched since the media didn't change; when the gallery isn't released, invalidate_and_arm returns None and this is a no-op. Mutation-verified: without it, an edit doesn't bump the epoch and the caption test fails. Also (test isolation): the compression worker now carries a generation counter that TRUNCATE bumps. A worker queued on the concurrency semaphore when a truncate wiped media would otherwise wake in the NEXT test, fail to find its file, and broadcast upload-error/upload-deleted into that test's SSE stream — corrupting any test asserting on toasts or feed. It now abandons itself when the generation moved. No-op in production (TRUNCATE is the only caller). Export workers were already inert across a truncate (epoch guard on a fresh-UUID event). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 19:48:15 +02:00
fabi	dd7b05415e	Merge branch 'test/admin-login-rate-limit-2026-07-15'	2026-07-15 19:10:41 +02:00
fabi	d2ad560df2	test(security): prove admin-login rate limit; make its toggle settable ... The admin-login IP rate limit already existed (auth/handlers.rs: 5/min/IP, gated by `rate_limits_enabled` + `admin_login_rate_enabled`, both default true in prod) — the earlier "no rate-limit or lockout" note was wrong. What was missing was any TEST of it: the e2e reseed sets `rate_limits_enabled=false`, so the old test observed all-401 under a disabled limiter and "documented" the opposite of reality. Replace that test with three that enable the limiter and prove it, mutation-verified (deleting the check in the handler fails the first two): - a burst of wrong passwords from one IP starts returning 429 (first is a normal 401, so the password path ran and the limiter had budget; none is ever 200) - once throttled, even the CORRECT password is refused — isolates the RATE LIMIT from the password check (this is the assertion that dies if the limiter is removed) - with `admin_login_rate_enabled=false` the same burst is NOT limited (the toggle gates it) Two fixes this surfaced: - `admin_login_rate_enabled` and `recover_rate_enabled` are read by their handlers but were missing from patch_config's BOOL_KEYS allowlist — the switches existed in code and could never be flipped. Added both. - Test isolation: exhausting the admin-login limiter locks out the NEXT test's truncate fixture, which must itself call admin_login before it can reset anything. An afterEach disables the toggle via patchConfig (JWT-based, not rate-limited) so the next login is clear; truncate then wipes the counter map. Runs on failure too. Full desktop suite 201 passed / 1 skipped; backend 56 tests; clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 19:10:41 +02:00
fabi	d452afb00e	Merge branch 'test/suite-audit-2026-07-15'	2026-07-15 07:27:02 +02:00
fabi	3f74c65787	ci: run the checks that only ran on a laptop; mobile in CI; retries 0 ... CI ran Playwright (chromium-desktop) + the dependency audit and nothing else. cargo test, clippy, the frontend vitest suite, svelte-check and the e2e typecheck were all green on a developer's machine and gated NOTHING. checks.yml (new): cargo test (with a Postgres service; --test-threads bounded so the sqlx per-test DBs can't exhaust connections) + clippy; vitest + svelte-check; e2e tsc. e2e.yml: also run the chromium-mobile project — 22 tests (focus traps, touch targets, safe-area, viewport reflow) that never ran in CI on a phone-first app. playwright.config: widen webkit-iphone beyond @smoke (2 specs) to the core guest journeys (auth/upload/feed) — iOS Safari is the PRIMARY browser here; and retries 2 → 0. retries:0 is deliberate and against the usual advice: this repo's real bugs are races, a race is indistinguishable from a flake from outside, and a retry resolves that ambiguity toward "flake" every time — it took a real 3%-flaky product bug from 1-in-33 to 1-in-37000, green. A flake here is a bug report. Not gated: cargo fmt (the tree has never been rustfmt'd — a 112-file reformat would bury every real diff; do it separately). WebKit widening is unverified locally (needs libavif16 via sudo), so its first CI run may surface real iOS bugs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 07:26:54 +02:00