2001 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Paul NothaftandPaul Nothaft	34ee31141b	fix(gallery): coerce SQLite 0/1 booleans in the guest surface (#1028) (#1034) ... SQLite stores booleans as 0/1, Postgres as true/false. The guest gallery compared strictly against `true`/`false`, so every flag read backwards on SQLite installs: allow_downloads: 0 !== false → true (header Download button shown with downloads disabled) allow_user_uploads: 1 === true → false (upload button hidden with uploads enabled) Worse, all five download guards used `allow_downloads === false`, which never fires against a stored 0 — so on SQLite "Allow photo downloads = off" was inert end to end: single photo, download-all, download-selected, download-jobs and the job-status poll all kept serving, as did the secure-images download route. Per-category blocking (#640) was ignored for the same reason, the protection toggles (right-click, devtools, canvas, watermark) reported false while enabled, overlay_protection was stuck on, and show_feedback_to_guests leaked feedback with the setting off. The /info endpoint was already correct — it checks 0/'0' explicitly. The two payloads had simply drifted. Everything now goes through parseBooleanInput (utils/parsers.js), which normalises both engines and takes a per-column default so legacy NULL rows keep their documented behaviour. Tests run on the SQLite harness, so they assert the real engine values. Every one of them fails on the unfixed code — the payload assertions return the inverted value, and the guard assertions never get their 403 (the request proceeds to serve instead). Claude-Session: https://claude.ai/code/session_0168gubtwYYacJv8weAjy8DM Co-authored-by: Paul Nothaft <[email protected]>	2026-08-13 18:50:48 +02:00
Paul NothaftandPaul Nothaft	671c4dbd56	fix(events): make event_date/expires_at nullable on SQLite (#1029) (#1035) ... Clearing a gallery's expiration failed on every SQLite install with SQLITE_CONSTRAINT: NOT NULL constraint failed: events.expires_at surfacing in the admin UI as "Failed to update event". Migration 061 added the event_require_event_date / event_require_expiration settings and dropped the NOT NULL on both columns — but only for Postgres. It skipped SQLite on the premise that "SQLite doesn't enforce NOT NULL as strictly", which is untrue, so "never expires" was never reachable there. The #426 work that allows clearing the expiration on edit therefore never worked on SQLite either. Migration 174 finishes 061 for SQLite. Knex implements .alter() on SQLite by recreating the table; migration 073 already does that on `events`, so the path is well-trodden. Postgres is skipped — it was handled in 061 and .alter() there would needlessly rewrite a column that is already correct. The test asserts against the real engine (the Jest harness runs SQLite) and reproduces the reporter's exact error without the migration. Claude-Session: https://claude.ai/code/session_0168gubtwYYacJv8weAjy8DM Co-authored-by: Paul Nothaft <[email protected]>	2026-08-13 18:50:42 +02:00
Paul Nothaft	e2832725ea	chore(main): release 3.102.1-beta.0 (#1026) v3.102.1-beta.0	2026-08-11 08:41:17 +00:00
Luca	27dedb13f3	docs: flip README links to docs.picpeak.app + delete docs/_to-migrate (#1000 phase 3) (#1023) ... Phase 3 (final) of #1000. The deep content now lives on the docs site (PicPeak/docs#7), making docs.picpeak.app the single source of truth and removing the in-repo copies. README links flip to docs.picpeak.app; the roadmap table is retired in favour of GitHub Issues. Deletes docs/_to-migrate/ and the five migrated pages. docs/migration-to-org.md stays — it's repo-transitional, not docs-site content. In-app references to the deleted files are repointed at the docs site, including the CRM disclaimer strings in en.json/de.json and the contract-editor fallback. Closes #1000.	2026-08-11 10:38:35 +02:00
Paul Nothaft	054c342c33	chore(main): release 3.102.0-beta.0 (#1025) v3.102.0-beta.0	2026-08-11 07:49:42 +00:00
Paul Nothaft	8e3573788b	feat(downloads): per-gallery download resolutions (#858) (#1022) ... Clients who need smaller files no longer make the photographer re-export. Two capabilities, both off by default. STANDARD RESOLUTION — the size a gallery hands out for every ordinary download (single, selected, download-all). Global default in Settings, overridable per gallery with the NULL=inherit tri-state. The pre-built download-all zip is built AT the standard resolution, so changing it invalidates those archives, including a fan-out to inheriting galleries. RESOLUTION PICKER — opt-in modal letting guests choose a different size. Custom archives are built as a DB-backed job the client polls, never cached. The picker never offers a size above the standard, and Original reappears only when the admin explicitly allows it. Resize is fit:'inside' + withoutEnlargement — aspect preserved, never upscaled — applied before the watermark, since the mark is sized relative to its input. Three rounds of external review hardened this: job archives are bound to the requester's visibility scope and re-validated at delivery, the streamed download-all path applies the cap, queue admission is bounded, and rejected resolutions no longer inflate download stats. Closes #858.	2026-08-11 09:46:46 +02:00
Paul Nothaft	02deac9f10	chore(main): release 3.101.5-beta.0 (#1021) v3.101.5-beta.0	2026-08-10 11:36:23 +00:00
Paul Nothaft	75bfad2b6a	fix(slideshow): stop "no crop" fit letterboxing a pre-cropped frame (#1015) (#1018) ... The slideshow resolved its image as preview_url || hero_url || url. preview_url is only emitted when lightbox_preview_enabled is on (default false), so a default install fell through to hero_url — the 1920x1080 fit:'cover' centre crop built for gallery header banners. object-fit: contain then letterboxed an already-cropped 16:9 frame, so portrait photos lost their top and bottom and 'Black Bars (No crop)' looked inert. Emits slideshow_url (same aspect-preserved preview tier) unconditionally for image photos; the show prefers it and never falls back to hero_url. preview_url stays gated so the lightbox opt-in is unchanged. Fixes #1015.	2026-08-10 13:32:14 +02:00
Paul Nothaft	08e0098597	chore(main): release 3.101.4-beta.0 (#1016) v3.101.4-beta.0	2026-08-10 09:03:45 +00:00
Paul Nothaft	e3830cd921	fix(deps): bump nanoid and js-yaml out of two HIGH advisories (#1013) ... Both are production dependencies of the backend image (npm ci --omit=dev): - nanoid 3.3.16 -> 3.3.18 (CVE-2026-67213, infinite loop in customAlphabet), transitive via postcss - js-yaml 4.3.0 -> 4.3.1 (GHSA-5p4m-2wfm-xmqj, quadratic CPU in !!omap resolution), direct dependency Lockfile-only; the existing ^ ranges already permitted both fixes. Clears the two open Trivy code-scanning alerts on main.	2026-08-10 10:59:53 +02:00
Paul Nothaft	03671f3b91	test(e2e): anchor the admin login button locator so SSO doesn't break it (#1012) ... With OIDC enabled the login page also renders a 'Sign in with <provider>' button whose accessible name matches the unanchored /Sign In/ locator, so Playwright strict mode failed every test that logs in — 7 of 13 in the local smoke suite, which is also the pre-push gate. CI never hit it because its databases seed without OIDC config. Anchors the regex to the full accessible name in all six call sites.	2026-08-10 09:53:18 +02:00
Paul Nothaft	5503e6ca5e	chore(main): release 3.101.3-beta.0 (#1011) v3.101.3-beta.0	2026-08-10 07:18:08 +00:00
Paul Nothaft	a607cea110	fix(auth): issuer-tag the oversize SSO logout marker (#798) (#1010) ... Phase 3 validated a stored ID token hint against the currently configured issuer, but the oversize path never got that check: an ID token above the 3.9KB cookie limit was stored as the bare string 'sso', which collapsed to an undefined hint at logout and skipped validation entirely. Changing the issuer while such a session was live bounced the user to the new IdP on logout. Stores sso.<base64url(issuer)> instead and moves all marker interpretation into buildEndSessionUrl: raw ID token -> iss/aud-validated hint, issuer-tagged marker -> round-trip without a hint, anything else -> no round-trip. Every branch fails closed. Refs #798.	2026-08-10 09:14:56 +02:00
Paul Nothaft	fbe1d07228	chore(main): release 3.101.2-beta.0 (#1009) v3.101.2-beta.0	2026-08-10 06:30:01 +00:00
Paul Nothaft	1bf19a7caf	fix(branding): route the gallery footer through <PoweredBy /> (#1008) ... Closes #1003. #999 centralised the attribution so branding_hide_powered_by is honoured everywhere, but GalleryLayout kept its own inline guard. The gallery footer therefore still flashed — it kept `!brandingSettings?.hide_powered_by`, where undefined is falsy, so a white-labelled instance briefly showed the attribution on first paint, on the surface a white-label customer is most likely to see. And there were two implementations of one rule, which is the bug class #999 existed to close. The footer appends the attribution to its copyright line inside an existing <p>, so a straight swap would nest a <p> in a <p>. Added an inline variant rendering a <span> that carries the leading ' | ' itself: the separator belongs to the component, since a caller placing its own would have to repeat the visibility guard to avoid leaving a dangling separator when the attribution is hidden. No extra request — GalleryView already uses usePublicSettings(), the same hook and react-query key, so the cache is shared. The footer also picks up common.poweredBy, so it is translated rather than hardcoded English. Removes the now-unread hide_powered_by from GalleryLayout's prop type and the mapping feeding it in GalleryView. Four cases cover the variant — span not paragraph, separator present, separator hidden with the attribution when white-labelled, hidden while loading. Each was checked against the pre-fix shape: rendering a <p> or moving the separator out breaks one.	2026-08-10 08:27:28 +02:00
Paul Nothaft	4ec93107a9	chore(main): release 3.101.1-beta.0 (#1007) v3.101.1-beta.0	2026-08-10 06:19:11 +00:00
LucaandLuca-Timo	ddebd50d3f	docs: slim README to a lean router, stage deep content for docs-site migration (#1001) ... Phase 1 of the README slim / docs-migration plan in #1000. README goes from 577 to ~191 lines: hero, one Quick Start, a Documentation index, comparison table, tech stack and a table of contents. The deep inline prose moves into a temporary docs/_to-migrate/ staging folder (webhooks, storage backends, first-run setup, system requirements, roadmap) so README links keep resolving until the docs-site pages are live. Existing docs/*.md referenced by app code are deliberately left in place — crm-disclaimers.md (frontend TSX, i18n, a backend route and migration), fonts.md (server.js), accounting-inbound-invoices.md (Dockerfile) and migration-to-org.md (UpdateNotification.tsx, MigrationBanner.tsx). Moving them is a separate, code-touching change. Verified before merge: merges cleanly against main with no conflicts; all 14 in-repo links resolve in the merged tree; no docs file is deleted or renamed; and the registry-move notice from #995 survives the rewrite in condensed form, keeping 'still responds but its tags are frozen at 2026-05-27' plus the migration-to-org.md link. The fuller symptom explanation remains in that doc, which the README links to. Follow-up per #1000: port docs/_to-migrate/* into docs.picpeak.app, then flip the README links and delete the staging folder. Co-authored-by: Luca-Timo <[email protected]>	2026-08-10 08:16:13 +02:00
Paul Nothaft	1c242d401f	test(transfers): pin the PicTransfer ownership guards (#1006) ... Closes #1005. The two ownership guards added during the #998 review were correct on merge but untested. They are the only thing between a scoped admin and every other admin's ORIGINAL files, since a transfer serves those over an unauthenticated token URL. 14 cases: filterOwnedPhotoIds (own / foreign / ownerless-legacy / mixed / non-existent / super_admin), addFiles gating on the same rule, listTransfers scoping plus the absence of token/upload_token/download_url/upload_url from the list payload, and getTransferOwner. Each was checked against the pre-fix behaviour rather than only passing against current code — reverting each guard in turn fails exactly the cases covering it: ownership filter 3, list scoping 1, payload strip 1, guard registered late 1. requireTransferOwnership is module-local, so its two contracts are asserted at the source following the #596 pattern: that router.use('/:id', ...) precedes every /:id route — ordering is the whole mechanism, and a late registration would guard nothing while still looking present — and that missing and foreign ids both answer 404, so the endpoint is not an existence oracle. Tests only; no production code touched.	2026-08-10 08:10:54 +02:00
Paul Nothaft	80599a5e47	chore(main): release 3.101.0-beta.0 (#1004) v3.101.0-beta.0	2026-08-09 11:43:36 +00:00
LucaandLuca-Timo	2e495d7c48	feat(transfers): add PicTransfer — cross-event file transfers (#998) ... Closes #997. Send original files from any event as a token-protected download link, with an optional client-upload channel. Strictly opt-in behind a new `transfers` feature flag, default OFF. Migrations 170-172 (transfers, transfer_files, transfer_extra_files, transfer_uploads, transfer_recipients, transfer_downloads, default settings and two email templates) — all hasTable/hasColumn-guarded and idempotent, with destructive statements confined to down(). Backend: transferService (CRUD, 256-bit download token, 6-char upload token, cross-event ZIP streaming of originals), admin CRUD routes, and two public token routes. transferCleanupService runs an hourly retention sweep; source-event photos are never touched. All three routers fail closed via requireFeatureFlag('transfers'). Review closed two ownership blockers, both the same root cause — permissions used where ownership was needed: - photoIds arrived from the request body and were validated only for existence, so a scoped admin could bundle any event's originals and hand them out through the public download token. filterOwnedPhotoIds now resolves ids to their events and gates them through filterOwnedEventIds, on both the create and add-files paths. - The transfer list was unscoped and carried each row's download token, so any admin with events.view could read another's token and fetch their originals. The list is now scoped by created_by, the token/url fields are stripped from the list payload, and a single router.use('/:id', requireTransferOwnership) covers all twelve /:id routes, 404ing foreign and missing alike. The admin photo picker filters its event list to the same rule, so the UI stops offering picks the API would discard. Fork-PR workflows had not been approved since the fix commits, so the PR's green checks were stale against the pre-fix head. Verified by dispatching tests.yml against the actual head: backend and frontend both green. Follow-up: neither ownership guard has a regression test yet. Co-authored-by: Luca-Timo <[email protected]>	2026-08-09 13:40:03 +02:00
Paul Nothaft	e2d8ec86bd	chore(main): release 3.100.2-beta.0 (#1002) v3.100.2-beta.0	2026-08-09 09:19:07 +00:00
Lutthyandlbossuyt	3bb4f1a1a8	fix(branding): hide "Powered by PicPeak" on every page, not only the gallery (#999) ... branding_hide_powered_by only hid the attribution on the main gallery footer. It stayed visible on the gallery password screen, client access page, Premium layout, admin and customer login, accept-invite and CMS pages — AdminLoginPage rendered it unconditionally with no guard at all, so the setting genuinely did not apply there. Routes those surfaces through one <PoweredBy /> component in components/common that reads the public setting itself (the DynamicFavicon pattern) and renders nothing when white-labeling is on, including while the settings are still loading so a white-labelled instance never flashes the attribution. Also collapses three duplicate translation keys (gallery.poweredBy, adminLogin.poweredBy, customer.login.poweredBy) into a single common.poweredBy, and translates pages that had 'Powered by' hardcoded in English across all 8 locales. Fork-PR workflows were never approved so CI did not run. Verified locally against cf243b44: tsc --noEmit clean, ESLint clean, vitest 124 passed across 24 files, and npm run build succeeds. GalleryLayout.tsx keeps its own inline guard and is not routed through the new component; tracked separately. Co-authored-by: lbossuyt <[email protected]>	2026-08-09 11:16:18 +02:00
Paul Nothaft	1f224f4ead	chore(main): release 3.100.1-beta.0 (#996) v3.100.1-beta.0	2026-08-04 15:33:44 +00:00
Paul Nothaft	b9e42591f5	docs: the retired registry path freezes, it does not stop serving (#995) ... Closes #985. README and migration-to-org.md both claimed the old path 'is no longer served'. It is served — ghcr.io/the-luap/picpeak/backend:latest returns a complete image, created 2026-05-27, label version: main. The registry responds normally; it just never receives anything new. That inaccuracy is what generates reports like #982. Told the path is not served, an operator runs docker compose pull, watches it succeed, runs docker rmi and pulls again, watches that succeed too, and concludes the problem lies somewhere other than their image path. Nothing reports an error anywhere; the only symptom is an update notice that never resolves. Say what actually happens — the path freezes rather than failing — and add a self-diagnosis via docker image inspect on both paths, with the 2026-05-27 date and the 'main' version label as the tells. MigrationBanner's wording is left alone: 'no longer being updated' was accurate. This is the delivery mechanism for #985. There is no in-app channel: MigrationBanner shipped a month after the freeze, the #993 update-check notice cannot fire on installs running their own frozen backend, and the changelog modal that renders release notes shipped two days after the freeze. What reaches these operators is GitHub, and the GHCR page for the retired package — which renders this README through the images' own org.opencontainers.image.source label, so the fix propagates to the dead path's own page automatically.	2026-08-04 17:30:18 +02:00
Paul Nothaft	9dc2b2166e	chore(main): release 3.100.0-beta.0 (#994) v3.100.0-beta.0	2026-08-04 14:52:13 +00:00
Luca	f00661511c	feat(gallery): admin preview skips the password on protected galleries (#981) ... Closes #868. A logged-in admin opening a published, password-protected gallery is let straight in, mirroring the existing draft-visibility bypass. Mechanism: an explicit ?admin_preview=1 intent flag AND a verified admin session read from the httpOnly admin_token cookie (or an admin-typed Bearer) — never a token from the URL. This retires the old ?preview=<raw-admin-JWT> scheme, which leaked a 24h admin token into the address bar, referrers and proxy logs. Per-request bypass only: no gallery JWT is minted, the password endpoint is never reached so the login_attempts lockout buckets stay clean, and admin previews are excluded from guest analytics (access_logs, download counts, per-photo view_count, notification bells). Review (two rounds) closed three blockers and two concerns: - Transport: verifyGalleryAccess now resolves admin preview before any gallery credential, and isAdminPreview reads the admin cookie first and type-checks every candidate — so an admin Bearer no longer 403s on the type gate, and a coexisting gallery session can no longer shadow the admin cookie. - Reveal mode (#838) is a second consumer of isAdminPreview; its bypass is unchanged, only the transport moves. revealMode.test.js updated off the retired scheme and now carries a coexisting gallery Bearer. - Admin previews no longer inflate per-photo view counts, and the internal photo redirects preserve the flag via withPreview() so they still authorise. - Happy path: GalleryPage renders GalleryView directly for a preview instead of attempting the public empty-password auto-login, which 401'd against a genuinely protected gallery and stranded the page on the skeleton. The backend job timed out once at the 10-minute CI limit; a re-run completed in 2m02s, in line with main's ~2m10s baseline, so that was a runner flake rather than a hang.	2026-08-04 16:48:07 +02:00
Paul Nothaft	137a42f259	feat(admin): surface the registry move through the update check (#993) ... Relates to #985 — does NOT close it. Adds registryMigrationRequired to the update-check payload (stable channel below 3.45.0) and an amber block in UpdateNotification explaining that the retired registry path still responds, so `docker compose pull` appears to succeed while serving the same frozen build. Known limitation, established in review and merged deliberately: this cannot reach the operators #985 describes. PicPeak is self-hosted, so the update-check code runs inside the operator's own image — a v3.44.0 install runs v3.44.0's backend forever, and the only external call returns release metadata, not logic. Every build containing this predicate is >= 3.45.0, where it is false by definition. The release-notes fallback fails too: the changelog modal shipped 2026-05-29, two days after the freeze. Correct for any future rename, no runtime cost, but #985 stays open — the population it describes still has no in-app channel. Viable routes are external (retired GHCR package description, repo README, docs). '0.0.0' is excluded from the predicate: that is getCurrentVersion's fallback for an unreadable package.json, i.e. a broken install, not a pre-rename one.	2026-08-04 16:36:50 +02:00
Paul Nothaft	0c8ad6bbed	fix(security): vet the destination project when linking a deal (#991) ... linkDealToProject re-points a deal's quotes, contracts and events into `projectId`. Its lineage guard vets the SOURCE events and its comment assumed the route had vetted the destination — true only for attachDocumentToProject. quoteService.create/update and contract crud.create/update take `projectId` straight from the request body behind quotes.manage / contracts.manage, which are permissions, not ownership; adminQuotes.js and adminContracts.js carry no ownership guard at all. The lineage guard did not cover it: it is skipped when the deal has produced no event yet, which is the state of a newly created quote, and an unassigned destination ADOPTS the deal's customer rather than rejecting it. A scoped admin could therefore write into another admin's project, and on an OWNERLESS project (created_by IS NULL — legacy rows migration 167 could not attribute) escalate to a read: once the quote converts to an event it becomes the project's only linked event, which is the condition ownedProjectsSubquery's second branch grants ownership on. Vetted at the service choke point all four callers share, ahead of both the null-deal early return (callers write project_id before calling, and deal_uuid is nullable) and the customer check (whose 422 vs 404 was an enumeration oracle). 404 PROJECT_NOT_FOUND throughout. super_admin unaffected.	2026-08-04 16:36:12 +02:00
Paul Nothaft	083b3d86b0	chore(main): release 3.99.2-beta.0 (#989) v3.99.2-beta.0	2026-08-04 12:40:03 +00:00
Paul Nothaft	6c03feaef5	fix(deps): bump ip-address, brace-expansion and postcss for open CVEs (#987) ... Closes Trivy code-scanning alerts #414-#418 on the backend image. brace-expansion 5.0.8 -> 5.0.9 CVE-2026-69152 (high) DoS via unbounded intermediate arrays ip-address 10.2.0 -> 10.4.0 CVE-2026-69192 (high), CVE-2026-54272 and CVE-2026-69198 (medium) — SSRF and trust-boundary bypasses. Needs 10.3.1+ to clear all three. postcss 8.5.18 -> 8.5.23 CVE-2026-69153 (medium) information disclosure via crafted sourceMappingURL ip-address and brace-expansion were already in overrides but pinned below the new fixed versions; the floors just needed raising. postcss reaches the image through sanitize-html — the direct pin is not an import, it forces the transitive copy to dedupe to a known version, so it moves with the bump. Only the backend image is affected: the frontend production stage is nginx:1.30-alpine and ships no node_modules. Each lockfile now holds exactly one entry per package, all at or above the fixed version, and the image installs via npm ci --omit=dev so the lockfile is authoritative.	2026-08-04 14:35:57 +02:00
Paul Nothaft	0ef836df19	chore(main): release 3.99.1-beta.0 (#986) v3.99.1-beta.0	2026-08-04 12:21:08 +00:00
Paul Nothaft	4b53b64277	fix(accounting): gate cross-add counters on the permission their endpoint checks (#984) ... Closes #983. The two cross-add counter queries added in #979 were enabled on customers.edit, but neither endpoint checks that permission: HoursSection -> GET /expenses/inbound/by-customer/:id needs accounting.view CustomerCrmPanels -> GET /customers/:id/hour-entries needs customers.view An admin holding customers.edit but not the corresponding read permission fired a guaranteed 403 on every customer-detail render. It degraded safely — the count stayed at its 0 default so the cross-add was never offered, which is the right outcome for that role — so this was request noise rather than broken behaviour. Each guard now requires both: the read permission to fetch the count, and the write permission because there is no point offering the cross-add to someone who cannot create the combined invoice. No seeded role is affected: migration 123 grants accounting.view and accounting.manage together, and customers.edit projects forward from customers.create, which migration 090 always grants alongside customers.view.	2026-08-04 14:17:34 +02:00
Paul Nothaft	83d514315e	chore(main): release 3.99.0-beta.0 (#980) v3.99.0-beta.0	2026-08-03 20:06:19 +00:00
Luca	165cebdb5c	feat(accounting): re-bill proof attachment, CRM panel & hours↔re-bills cross-add (#979) ... Closes #866. Three features, all behind the `incomingInvoices` feature flag: 1. Attach the stored supplier proof PDF to the client-invoice email when a captured invoice is re-billed/passed through, as a SEPARATE attachment so invoice immutability holds. Global default (off), per-customer tri-state override, and per-file selection in a new Send dialog. A missing proof at issue time stamps inbound_documents.proof_attach_error rather than silently dropping, and never blocks the send. Proof filename is a configurable template with {INVOICE} {SUPPLIER} {YEAR} {MONTH} {SEQ}/{SEQ:0Nd} tokens. 2. Re-bills & passthrough panel under CRM → Customer, grouped Open/Sent/Paid with status derived from the linked invoice lifecycle rather than a duplicated column. 3. Cross-add dialog rolling open hours and open re-bills into one invoice, symmetric from both entry points. The two stay distinct, contiguous line groups — never merged into shared line items. Migration 169 is additive, hasColumn-guarded and idempotent. Review (two rounds) closed two concerns: - Storno stranding: nothing cleared inbound_documents.billed_invoice_id when a covering invoice was cancelled, so a Storno'd re-bill showed as Open in the new panel while every billing path filters on that column being NULL — the supplier cost could never be re-billed. releaseRebillsForCancelledInvoice now detaches the linkage on both invoice-cancel paths, with a regression test on the issued-cancel path. - Permission gating: the new controls rendered on data presence alone while their endpoints require accounting.view / accounting.manage / customers.edit. Now gated at both the query and render layers. Known follow-up: two cross-add counter queries are gated on a permission their endpoint does not check (HoursSection.tsx:174, CustomerCrmPanels.tsx:270) — degrades safely, one line each.	2026-08-03 22:03:31 +02:00
Paul Nothaft	d66425c8ee	chore(main): release 3.98.6-beta.0 (#978) v3.98.6-beta.0	2026-08-03 12:52:55 +00:00
Paul Nothaft	67592fc569	fix(projects): stop the cockpit offering email controls the API rejects (#976) ... Closes #969. The cockpit's email feed rendered preview/resend/cancel/retry/send-now for every mail, consulting neither the caller's role nor their permissions, producing controls that always failed: 404 - requireOwnedQueuedEmail scopes queued mail through email_queue.event_id AND ownership of that event. CRM document mail carries no event_id; and project ownership does not imply event ownership, so a project the caller owns can hold another admin's event. 403 - preview needs events.view but the four write actions need email.send. getProjectOverview now stamps each email with an authoritative canAct, mirroring filterOwnedEventIds; created_by is selected only for that check and stripped before the response. The cockpit reads canAct and combines it with email.send. A missing canAct reads as false. Regression from the GHSA-93x4 fix in #960/#966, which added the ownership middleware.	2026-08-03 14:48:50 +02:00
Paul Nothaft	6699855c93	fix(auth): fail closed when the adminAuth roles join errors (#974) ... Closes #968. The roles-join fallback in adminAuth fabricated role_name='super_admin' on ANY database error, so a transient fault (connection reset, deadlock, statement timeout, pool exhaustion) silently granted super_admin for its duration. roleName is the sole discriminator for every ownership check, so this inverted the authorization model rather than failing the request. Gate the fallback on isMissingRolesSchema(), moved to utils/dbErrors.js and shared with apiTokenAuth. The predicate was also tightened: knex prefixes the failing SQL to err.message and that SQL always names `roles`, so the old /roles/i gate was vacuous and a generic /does not exist/ could accept unrelated faults. Now trusts SQLSTATE 42P01/42703 on Postgres and exact driver phrasing on SQLite.	2026-08-03 14:48:20 +02:00
Paul Nothaft	569ae39acb	chore(main): release 3.98.5-beta.0 (#973) v3.98.5-beta.0	2026-08-02 19:27:37 +00:00
Paul NothaftandPaul Nothaft	7c0c0a5b7f	fix(security): enforce project ownership on project + project-email routes (GHSA-wrg5, GHSA-93x4) (#960) ... * fix(security): enforce project ownership (GHSA-wrg5, GHSA-93x4) Project routes authorized on generic events.view / events.edit with NO ownership check, so an editor-like admin could enumerate, read, update and aggregate projects belonging to other admins' events. The project email endpoints keyed on an email_queue id alone — any admin with events.view / email.send could preview, resend, cancel or retry ANY queued mail by walking ids. The earlier 'needs a migration, deferred' assessment was wrong in one direction and right in another: ownership IS derivable transitively via events.project_id -> events.created_by, but only for projects that already have a linked event. A brand-new EMPTY project has no derivable owner, which is exactly where the create -> attach flow starts. So migration 167 adds projects.created_by (backfilled from the single linked event owner, skipping ambiguous multi-owner projects) and createProject finally persists the adminId it was already being passed. - ownedProjectIds(): union of the stored owner and the transitive path, so pre-167 rows and new empty projects both resolve. Reads created_by defensively so an instance that hasn't run 167 falls back to the transitive rule instead of throwing. - requireProjectOwnership on detail/update/attach-event/attach-quote/ attach-contract/overview; list filtered by an id allowlist (empty array means 'owns nothing' and must return no rows, hence null-vs-[] care). - POST /:id/events also validates the INCOMING eventId — owning the project is not enough, or an editor could pull a foreign event in and read its rolled-up documents via /:id/overview. - Queued-email routes scoped via email_queue.event_id. CRM document mail has event_id NULL and no ownable parent here, so a scoped caller is denied rather than guessed into access. 404 (not 403) so it isn't an id oracle. Note: adminEmail.js:315/332 let any email.view/edit admin archive or delete any email_queue row — the same class, pre-existing and outside these two advisories. Left untouched and reported rather than silently widened. * fix(security): codex round 2 — make the stored project owner authoritative (GHSA-wrg5) The first predicate union'd 'any linked event I can see' with the stored owner, which opened two holes: - A project owned by admin B containing ONE legacy ownerless event became readable by every admin — and /:id/overview aggregates B's other events, invoices and emails, so a single legacy event exposed the whole project. - Migration 167 deliberately leaves multi-owner (ambiguous) projects NULL rather than guessing an owner. A NULL owner was then treated as 'everyone's', so exactly those mixed projects became globally accessible. Now: the stored created_by wins outright, and a project without a usable stored owner only derives access when EVERY linked event is accessible (and at least one exists). A created_by pointing at a hard-deleted admin degrades to 'no usable owner' so the project falls back to its events instead of being locked away — no ON DELETE SET NULL migration needed. A project with neither a usable owner nor linked events stays super_admin-only: failing closed beats failing open, and a super_admin can reassign it. Also returns a knex SUBQUERY rather than a materialised id list, so a large project count can't hit the driver's bind-parameter limit. * fix(security): codex round 3 — enforce deal-lineage ownership on project attach (GHSA-wrg5) requireProjectOwnership vets only the DESTINATION project, while attaching a quote or contract cascades through linkDealToProject — which re-points every event the deal produced into that project. An editor could therefore create an empty project of their own, attach another admin's quote, and pull that admin's events (plus the invoices, emails and gallery that roll up with them) into a project they own and can read via /:id/overview. The single-customer guard did not stand in the way: an unassigned project ADOPTS the deal's customer rather than rejecting it. linkDealToProject now refuses to move lineage events the actor cannot own, and assignDocument cascades BEFORE stamping the document so a refused attach leaves nothing half-applied (the old order committed the foreign document into the caller's project and only then declined the cascade). The quote/contract create+update paths, which reach the same cascade with an arbitrary project_id, thread their adminId through as well; isSuperAdmin() resolves the role for them and fails closed when it cannot. Events are the only ownership signal a deal carries — quotes and contracts have no created_by in this schema — so a lineage that produced no event still cannot be attributed. That is a property of the CRM model, noted in the code. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me * docs(security): drop the stale ownership JSDoc left by the rebase (GHSA-wrg5) Rebasing onto main (which had gained scopeEventsQuery from #957) replayed the round-1 doc block above round-2's replacement, leaving a comment that describes the ORIGINAL union rule — "a project is the caller's when … it has at least one linked event they own" — directly above the code that deliberately no longer does that. That union is the hole round 2 closed; a comment asserting it is worse than none. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 21:24:38 +02:00
Paul Nothaft	3fc6463873	chore(main): release 3.98.4-beta.0 (#971) v3.98.4-beta.0	2026-08-02 19:22:22 +00:00
Paul NothaftandPaul Nothaft	164129b8f5	fix(security): escape brand tokens, block tracker redirects, trim logo diagnostic (GHSA-j347, mw76, 29vm) (#961) ... * fix(security): escape brand tokens, block tracker redirects, trim logo diagnostic (GHSA-j347, mw76, 29vm) GHSA-j347 — buildCachedPayload sanitizes the operator's HTML and THEN runs applyBrandTokens over the result with a plain String.replace, so any markup in a token value reached the public origin unfiltered. The default templates interpolate tokens into text AND into quoted attributes (<img src="{{brand_logo_url}}" alt="{{company_name}} logo">, href="mailto:{{support_email}}"), so a value could close the attribute and inject. Token values are now HTML-escaped on substitution, mirroring galleryOgService's escapeHtml. sanitizeBrandUrl's case-sensitive literal 'javascript:' check (which 'JavaScript:' walked straight past) is replaced by an http/https scheme allowlist; relative logo paths are unaffected. Writer is settings.edit (super_admin only) and the CSP blocks inline script, so this is defence-in-depth — but sanitize-then-substitute is a real ordering bug regardless. GHSA-mw76 — the SSRF decline STANDS: self-hosted operators legitimately point analytics at private addresses, so connection-time IP blocking would break real deployments. Fixed only the narrow leak: undici strips Authorization/Cookie/Proxy-Authorization/Host across a cross-origin redirect, but umamiAdapter sends a CUSTOM x-umami-api-key header, which would be replayed verbatim to the redirect target. Both adapters now use redirect: 'error'. GHSA-29vm — the logo diagnostic echoed absolute storage roots, process.cwd() and absolute candidate paths. It now reports candidates relative to <STORAGE>/<CWD_STORAGE>, which answers the same 'which candidate existed' question. It also still advertised the raw-absolute candidate that GHSA-c7x5 removed from resolveLogoFile, so it was misreporting what the resolver tries — aligned with the real candidate list. publicSiteService.test.js expectation updated: an '&' in a company name is now emitted as '&amp;'. Renders identically; the raw payload string differs. * fix(security): codex round 2 — stop the remaining logo-path disclosure, mirror the resolver (GHSA-29vm) - sources[].value was still echoed verbatim. branding_logo_path is stored ABSOLUTE by multer, so relativising only resolvedTo and the candidate paths left the filesystem layout going out anyway. It is now relativised too. - Round 1 dropped the raw-absolute candidate on the grounds that GHSA-c7x5 removed it from resolveLogoFile — but the c7x5 follow-up RE-ADDED it (kept, subject to the containment filter, so a legitimate multer path still resolves). The diagnostic therefore reported every candidate as missing for a contained absolute logo while resolvedTo named the file. It now mirrors the resolver, containment filter included. One deliberate cosmetic divergence, commented in place: for an absolute value the resolver also tries path.join(root, value-minus-leading-slash), which can never exist and would re-embed the absolute path this endpoint must stop echoing. Omitted; every candidate that can actually match is still shown. * fix(security): codex round 3 — mirror the resolver for root-relative logo paths (GHSA-29vm) The logo diagnostic skipped the `<STORAGE>/<value>` candidates whenever path.isAbsolute(value) was true. That test cannot distinguish a multer disk path from a root-relative URL such as `/custom/logo.png`, and for the URL form resolveLogoFile.generateCandidates() does try `<STORAGE>/custom/logo.png` and can resolve it — so the endpoint reported "no source candidate exists" about a logo that renders fine, and collapsed the configured value to its basename. The stripped joins are now built unconditionally, exactly as the resolver does. Disclosure stays closed: every candidate still passes the containment filter and redact() rewrites survivors to `<STORAGE>/…`, never an absolute host path. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me * fix(security): gate the logo stripped-joins on containment, not isAbsolute (GHSA-29vm) The previous commit dropped the isAbsolute() gate entirely and regressed logoDiagnostic's own disclosure assertion: for a genuine multer disk path, path.join(root, value-minus-leading-slash) yields `<STORAGE>/tmp/…/storage/custom/logo.png`, and redact() only rewrites the LEADING root — so the inner absolute path went straight back into the payload. The right discriminator is not "is this absolute" (which cannot separate a disk path from a root-relative URL) but "does the value already resolve inside a storage root". If it does, it is a real disk path, the raw candidate already covers it, and the stripped join is the double-prefixed junk that can never exist. If it does not — the `/custom/logo.png` URL form — the stripped join is exactly what resolveLogoFile resolves, and is shown. Covered by a new case asserting both halves: the candidate appears for the URL form, and the payload still contains neither the storage root nor cwd. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 21:17:17 +02:00
Paul NothaftandPaul Nothaft	e2ce95ee48	fix(security): enforce event ownership on the v1 API surface (GHSA-9697) (#957) ... * fix(security): enforce event ownership on the v1 API surface (GHSA-9697) Migration 081 documents the intent — 'the token's effective permissions are the intersection of the user's role permissions and the token's own scope flags' — but it was never implemented. - apiTokenAuth selected only id/username/email/role_id, so req.admin.roleName was undefined. Every ownership helper keys on roleName, so the v1 surface could not tell a super_admin from a demoted viewer. Now joins roles and emits the same req.admin shape adminAuth does, including the roles-table-missing upgrade fallback. - No v1 route applied any ownership predicate: GET /events listed every event on the instance, and GET /events/:id/share-link returned ANY event's share_token — the gallery access credential, same class as GHSA-rh8r. List is now scoped via a new scopeEventsQuery helper; the three :id routes (detail, photo upload, share-link) use the existing requireEventOwnership. Not a breaking change: tokens are minted by super_admins, who bypass ownership. It closes the case where a token's owner is later demoted — userManagementService never touches api_tokens, so the token outlived the demotion with full read of every gallery's share token. events.category.test.js stubbed apiTokenAuth without roleName; giving the stub super_admin keeps requireEventOwnership from issuing a DB query and desyncing that suite's sequenced dbMock. * fix(security): codex round 2 — intersect v1 token scopes with role permissions (GHSA-9697) Ownership scoping alone left half the documented control missing. Migration 081 defines a token's effective permissions as the INTERSECTION of the owner's role permissions and the token's scope flags; requireApiScope only ever checked the scope half. A token minted while its owner was super_admin therefore kept write access after the owner was demoted to viewer — userManagementService never touches api_tokens, so the token outlives the demotion, and ownership scoping does not help because the demoted owner still owns their events. Adds requirePermission to all six v1 routes (events.create on create, events.view on the reads, photos.upload on upload). It keys on req.admin.id, which apiTokenAuth already populates. The two existing v1 suites mock the database, so a real permission lookup 500s — they now mock the permissions middleware as pass-through, matching how they already mock apiTokenAuth. Those suites cover route logic; the intersection is pinned by the new v1TokenPermissions suite. * fix(security): codex round 3 — fail closed on the roles-join fallback (GHSA-9697) The round-2 fix loaded the token owner's role so the v1 ownership checks could tell a super_admin from a demoted viewer, and mirrored adminAuth's roles-table-missing fallback. That fallback assigns role_name = 'super_admin', and the catch around it was unconditional — so ANY failure of the joined query (connection reset, deadlock, statement timeout) elevated the token owner to super_admin as long as the simpler fallback query then succeeded. A restricted owner could ride that into listing, reading and share-tokening every event on the instance, which is the exact hole GHSA-9697 closes. The fallback is now reached only for an error that genuinely names a missing roles table/column (PG 42P01/42703 or the SQLite/MySQL wording); anything else propagates to the 500 handler. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 21:17:14 +02:00
Paul NothaftandPaul Nothaft	1b4e5fee3e	fix(security): bound inbound-mail resources, redact secrets from logs (GHSA-2qf9, pgmp, r794) (#959) ... * fix(security): bound inbound-mail resources, redact secrets from logs (GHSA-2qf9, pgmp, r794) GHSA-2qf9 — emailIntakeService downloaded, parsed and persisted every message with no size, attachment-count or attachment-byte limit, reachable unauthenticated by anyone who can email the operator's mailbox: - fetch the envelope with `size` (same cheap pass) and refuse an oversized message BEFORE downloading its source; - cap attachment count and cumulative attachment bytes; - limits env-overridable, defaults generous for real supplier invoices. The teeth were in the dedup key. received_emails.message_id is varchar(512) UNIQUE, and the failure path wrote `err-<uid>-<Date.now()>`, which can never match the envelope-derived messageId the dedup pass compares against — so an oversized (or overlong-Message-ID) mail was re-downloaded every poll forever, and an OOM-kill/restart just resumed the loop. Size-skips are now recorded under the REAL message id, and overlong ids collapse to a stable sha256 key that always fits the column. GHSA-pgmp / r794 — new sanitizeForLog() util (key-name deny-set, recursive, cycle-safe) applied to the three request-body log sites in adminEvents/crud.js, plus sanitizeValidationErrors() because express-validator's errors.array() embeds the SUBMITTED value per field — a rejected plaintext password was still logged. Scope is wider than filed: the update path also logged client_password_hash and a LIVE client_share_token bearer credential. Also: the one-time setup token was logged at warn AND printed to stdout on every first boot, putting a live first-admin credential in combined.log, security.log and `docker logs`. It is now written to the 0600 token file and only surfaced when that write fails — the last-resort path it existed for. * fix(security): codex round 3 — repair the first-run token recovery flow (GHSA-r794) Two regressions from keeping the setup token out of the logs. 1. server.js decided whether to print the token by calling existsSync() on the candidate path. That answers a different question than "did the write succeed": a stale, read-only or directory-shaped SETUP_TOKEN reports as present, so the banner suppressed the live token and pointed the operator at content that is not it — leaving the current token only in combined.log under default production logging. setupService now records the path the write actually produced and exposes it via writtenSetupTokenFile(). 2. The setup screen, its EN/DE strings, README, SIMPLE_SETUP and .env.example all still told first-time users to run `docker compose logs backend | grep -i "setup token"`. On the normal path that command now returns a path banner and no credential, so the documented browser-first onboarding could not be completed. They now point at `docker compose exec backend cat /app/data/SETUP_TOKEN`, with the log fallback described as what it is — the failure path. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 21:17:11 +02:00
Paul NothaftandPaul Nothaft	da855cfef9	fix(security): scope dashboard stats/analytics/activity to the caller's events (GHSA-c2jj, gqx7, jhcf) (#958) ... * fix(security): scope dashboard endpoints to the caller's events (GHSA-c2jj, gqx7, jhcf) /dashboard/stats, /analytics and /activity are gated only by analytics.view, which the editor role holds — but the events LIST restricts editors to their own rows (adminEvents/crud.js: roleName === 'editor' -> created_by = admin.id). So an editor saw instance-wide totals, and via /analytics topGalleries other admins' gallery NAMES and SLUGS (the public gallery URL component), for events invisible to them everywhere else. - stats: all 10 aggregates scoped (events by id, photos/access_logs by event_id). - analytics: all 8 series/aggregates scoped, including topGalleries. The external tracker device breakdown reports instance-wide data with no event filter, so a scoped caller falls through to the access_logs heuristic instead, which IS scoped. - activity: feed scoped. activity_logs.event_id is nullable and the join is a leftJoin, so system-level rows (logins, settings changes) are deliberately excluded for a scoped caller — those are precisely the cross-admin actions the advisory is about. Scoping keys on 'editor' to mirror the events list exactly, so the admin role's dashboard is unchanged. filterOwnedEventIds uses the broader '!== super_admin' rule; the two conventions disagree in this codebase and matching the list is the no-regression choice. * fix(security): codex round 2 — fix activity misattribution, scope via subquery (GHSA-jhcf, c2jj, gqx7) - expenseService passed adminId as logActivity's THIRD positional parameter, which is eventId — so admin ids were being written into activity_logs.event_id. The /activity scoping filter trusts that column, and admin/event id sequences overlap, so a foreign admin's expense metadata could surface under an editor's event. All 11 calls now pass null for eventId and the admin as the actor, which is what they meant. - Dashboard scoping now uses a SUBQUERY instead of pluck()+whereIn. An editor owning more events than the driver's bind-parameter limit (~999 SQLite, 65535 Postgres) would have turned all three endpoints into 500s once each id became a placeholder; below the limit it still re-sent the full list for each of the ~10 aggregates per request. Note: two billInboundNow() calls also end in ', adminId)' but have an unrelated signature — verified untouched. * fix(security): codex round 3 — correct legacy accounting activity rows (GHSA-jhcf) expenseService called logActivity(type, metadata, adminId), but logActivity's third positional parameter is eventId. Every expense / incoming-invoice entry therefore stored the ACTING ADMIN'S ID in activity_logs.event_id. Round 2 scoped the activity feed with `WHERE activity_logs.event_id IN (SELECT id FROM events WHERE created_by = me)`, which does nothing about the rows already on disk. Admin ids and event ids are small integers from the same range, so on any upgraded instance an editor who owns the event whose id happens to equal another admin's id is served that admin's accounting activity, verbatim metadata included — GHSA-jhcf, still live. Migration 168 re-attributes those rows (event_id holds exactly the actor id that was lost) and then clears event_id so the scope predicate can no longer match them. All ten activity types are emitted by expenseService and nothing else, so no row with a genuine event_id is touched. Also: the round-2 rewrite passed `{ type: 'admin', id: adminId }` unconditionally, which stored actor_type='admin' with a null id for the automated mailbox intake (emailIntakeService calls recordInboundDocument with no adminId). adminActor() restores 'system' attribution for those. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 21:17:08 +02:00
Paul NothaftandPaul Nothaft	0d4c30884e	fix(security): backup/restore hardening — public-dir DB dump, restore path allowlist, gunzip bound, manifest keying (#956) ... * fix(security): stop caller-chosen database backup destination (GHSA-jw8m) POST /api/admin/database-backup/backup forwarded req.body straight into databaseBackupService.backup(), which merges options over config: const { destinationPath = '/backup/database', ... } = { ...config, ...options } destinationPath is not a persistable setting — the /config allowlist only accepts database_backup_* keys — so the request body was its only source. The built-in `admin` role holds backup.create but neither settings.edit nor backup.restore, so it could aim a full DB dump (admin bcrypt hashes, gallery password hashes, encrypted SMTP creds) at the PUBLIC /uploads static mount (server.js mounts it with no auth middleware) and then fetch it unauthenticated. Filed low; it is a privilege escalation to unauthenticated disclosure. Forward only the real knobs, and only when present so absent keys can't override config defaults via spread. * fix(security): backup/restore hardening — restore path allowlist, gunzip bound, manifest checksum keying (GHSA-fw4c, h652, hgp8) - adminRestore /validate + /start: constrain caller-supplied source and manifestPath to the operator-configured backup roots — the SAME set the restore wizard discovers from — so disaster recovery from a rescued mount still works, with RESTORE_ALLOWED_ROOTS as an escape hatch (GHSA-fw4c). - restoreService.decompressFile: bound the EXPANDED size and abort the pipeline when exceeded; default 50 GB, RESTORE_MAX_DECOMPRESSED_BYTES overrides (GHSA-h652). - backupManifest: BACKUP_MANIFEST_KEY upgrades new manifests to a keyed HMAC (GHSA-hgp8). Deliberately opt-in and verify-if-present — the key cannot live in the database because the database is inside the backup, so a mandatory HMAC would lock operators out of the exact disaster-recovery case this exists for. Also fixes a pre-existing bug found while testing hgp8: the checksum passed Object.keys().sort() as JSON.stringify's second argument, which is an array REPLACER (a property allowlist applied at every depth), not a key sorter. All nested keys — path, size, per-file checksum — were dropped before hashing, so the file list sat outside the integrity check entirely and a manifest path could be rewritten to ../../etc/passwd without disturbing the digest. Now hashes a recursively-canonicalized copy, with the legacy serialization accepted on validation so existing backups stay restorable. * fix(security): codex round 2 — unbreak the restore wizard, share checksum verification, guard downgrades - adminRestore: `source` is usually a SOURCE TYPE ('local'|'s3'|'upload'), not a path — restoreService branches on those literals. The containment check treated it as a path, so path.resolve('local') fell outside the backup roots and BOTH /validate and /start returned 400, blocking every normal restore. Type tokens are now excluded from the path check. - backupManifest: extracted verifyManifestChecksum() as the single source of truth for the legacy/keyed fallbacks. restoreService.performPreRestoreValidation recomputed the digest itself with the default canonical+keyed settings, which rejected EVERY backup written before this batch. It now delegates. - backupManifest: guard the algorithm downgrade — with a key configured, an attacker able to rewrite the backup store could strip checksum_algorithm, edit the manifest and recompute a plain SHA-256 that verified. Opt-in via BACKUP_MANIFEST_REQUIRE_KEYED so pre-key backups keep restoring by default. * fix(security): codex round 3 — close two manifest-verification fail-opens (GHSA-hgp8) verifyManifestChecksum returned valid for a manifest with no verification.total_checksum at all, and restoreService only called it when that field was present. Deleting the field was therefore a complete bypass of the keying work: no digest check, no downgrade guard, no BACKUP_MANIFEST_REQUIRE_KEYED. Every manifest this codebase writes stamps the field, so an absent one now fails validation, and the call site invokes the verifier unconditionally. Second fail-open: the strict-mode rejection of an unkeyed manifest was gated on `&& key`, so with BACKUP_MANIFEST_REQUIRE_KEYED=true and no BACKUP_MANIFEST_KEY configured a plain SHA-256 manifest sailed through. Strict mode is a statement about the operator's manifests, not about the host — it is exactly the fresh disaster-recovery box that lacks the secret. The rejection no longer depends on a key being present. Claude-Session: https://claude.ai/code/session_01F211U4dDbEj4zXiyKbi9me --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 21:17:05 +02:00
Paul Nothaft	acd6b453d1	chore(main): release 3.98.3-beta.0 (#954) v3.98.3-beta.0	2026-08-02 20:25:32 +02:00
Paul NothaftandPaul Nothaft	1c8f7d58a8	fix(security): redact gallery share tokens from analytics tracking (GHSA-7m6c) (#952) ... * fix(security): redact gallery share tokens from analytics page-view tracking (GHSA-7m6c) * fix(security): codex round-1 — actually disable raw auto-tracking (GHSA-7m6c) The previous patch was inert: App.tsx passed autoTrack:true (so Umami's data-auto-track=false was never set) and the sanitized trackPageView had no caller (useAnalytics sits outside <Router>), so the raw token URL still hit the collector. - Umami: drop autoTrack:true → data-auto-track=false; page views now come from a sanitized manual tracker. - Rybbit: its initial-load auto pageview can't be intercepted client-side, so use native data-mask-patterns=['/gallery/**'] to strip the token on every auto-tracked view; skip manual tracking for it to avoid double counting. - Mount <AnalyticsRouteTracker/> INSIDE <Router> so manual tracking runs. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 08:38:33 +02:00
Paul NothaftandPaul Nothaft	c2ce12c039	fix(security): authz/ownership gaps (token binding, auth revocation, feedback/customer ownership, token logging) (#950) ... * fix(security): close authz/ownership gaps (secure-download binding, photo-auth+logout revocation, feedback/customer ownership, token logging) * fix(security): codex round-1 — complete admin-token invalidation + preserve foreign assignments - photoAuth: mirror adminAuth's active-admin lookup + iat<password_changed_at check in the admin branch, so a deactivated admin or a pre-password-change token can no longer fetch every photo (GHSA-x55x was only revoke+cutoff). - adminAuth logout: revoke req.token (the token adminAuth authenticated with, cookie OR header) instead of header-only, and clear the auth cookie — a cookie-based logout previously left the JWT live (GHSA-cjqh). - adminCustomers PUT /:id/events: preserve the customer's existing assignments to events the caller does NOT own, so a restricted admin can't revoke another admin's customer-event links via full-list replacement. * fix(security): codex round-2 — don't 403 legit restricted-admin assignment edits The Manage-galleries dialog submits the full initial assignment list, so a restricted admin editing a customer that already has a foreign assignment hit the denied.length 403 before the preservation logic ran. Reject only NEWLY-supplied foreign/nonexistent ids; retain foreign ids the customer is already assigned to (they can't be added or removed by a non-owner). --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 08:38:24 +02:00
Paul NothaftandPaul Nothaft	8f91c2ca99	fix(security): neutralize spreadsheet formulas in all CSV/export cell-writers (CSV injection cluster) (#948) ... Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 08:37:56 +02:00
Paul NothaftandPaul Nothaft	9050affd8d	fix(security): unauth share_token leak (HIGH) + restore path-traversal, logo file-read, branding path keys (#946) ... * fix(security): stop unauth share_token leak + block restore path-traversal, logo-path file read, branding path keys * test: update resolveLogoFile for the c7x5 containment (reject outside-storage absolute paths, keep inside) * fix(security): codex round-1 — escape LIKE wildcards in share-link resolve, keep in-storage absolute logos, guard restore verification - shareLinkService: escape %/_ in the link_partial LIKE fallback so an anonymous /resolve/____… wildcard can't match an arbitrary share_link and leak its bearer token (reopened GHSA-rh8r). Explicit ESCAPE for SQLite. - resolveLogoFile: re-add the raw absolute candidate but keep it subject to the storage-root containment filter (GHSA-c7x5) so legit in-storage absolute logos resolve while /etc/passwd stays rejected. - restoreService: apply the same pathEscapes guard in post-restore verification so a skipped traversal entry isn't fs.access'd/hashed. --------- Co-authored-by: Paul Nothaft <[email protected]>	2026-08-02 08:37:48 +02:00