4 Commits

Include renames

Author	SHA1	Message	Date
PaddyandClaude Opus 5	b848d6eab9	Move the calendar onto the shared session cookie ... Step 4 of docs/calendar-auth-migration.md, and the close of DEFERRED_SECURITY.md item 1: no calendar route reads sessionId/sessionKey from the query string any more, so a live credential no longer travels through access logs, browser history and Referer headers. The four write routes sit behind requireAppAccess('calendar'), which also narrows who may edit from "any activated @nachklang.art account" to an explicit per-user permission. They answer 401 signed out and 403 without the permission, where they previously answered 403 for both. The three read routes cannot use the middleware: one URL serves an anonymous visitor, an iCal subscription holding a shared password, and a signed-in editor who should see drafts. They resolve the session optionally instead, and a signed-in user without the calendar permission is treated as anonymous rather than refused - so they keep the public calendar access anyone has. That public calendar staying anonymous is load-bearing: nachklang.art reads it to show the next upcoming event. It is now pinned at both the password-table and the route level, and so is the rule that a shared password can never be used to write. credentials.service.ts loses its session half and becomes the password table it always wanted to be. The shared passwords survive only for iCal clients, which cannot send a cookie. Writes record the author as an admin user id and no longer have a legacy int to write, which is what migration 003 makes room for. /calendar/users/* is left in place: nothing calls it and a session it mints opens nothing, but they are still live password-accepting endpoints, so removing them belongs with the rest of the legacy path in step 5. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 22:23:36 +02:00
PaddyandClaude Opus 5	61d3883479	Read calendar event creators from the admin module, and archive the old ones ... Steps 1 and 3 of docs/calendar-auth-migration.md. The calendar is the last module still authenticating against its own users/sessions tables; this is the groundwork that lets step 4 swap it for the shared admin identity. An event now records its creator twice: created_by_id, the legacy INT into the calendar database's own users table, and created_by_user_id, the admin module's VARCHAR(36) id. The two live in different databases, so there is no foreign key and no join - a cross-schema reference would tie the schemas' lifecycles together, and the name is instead resolved through one lookup per result set against the admin database. The creator is only ever rendered as a name; nothing authorises on it. That is what makes the planned account backfill unnecessary - dropped by decision - and what makes the read degrade rather than fail: an admin id that no longer resolves falls back, and an unreachable admin database costs a name rather than the response. The public calendar is read anonymously by nachklang.art and has never depended on the admin database being up. Since there is no backfill, step 5 dropping the legacy users table would have erased the authorship of every pre-cutover event. Migration 002 brings that part of step 5 forward and snapshots the names onto the events themselves, so the data is safe well before the table holding it goes away. The same SELECT and row mapper existed in four copies; collapsed to one of each first, so the dual read is written once rather than four times. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-06 22:09:21 +02:00
Paddy	bf7be65b03	Add admin identity module: better-auth, per-app permissions, invitations (#12) ... Reviewed-on: #12 Co-authored-by: Patrick Müller <mail@pmueller.me> Co-committed-by: Patrick Müller <mail@pmueller.me>	2026-09-06 10:41:54 +00:00
Paddy	3c4f3331d8	Add Tickets domain for the voucher-based ticket shop (#8) ... Reviewed-on: #8 Co-authored-by: Patrick Mueller <patrick@mueller-patrick.tech> Co-committed-by: Patrick Mueller <patrick@mueller-patrick.tech>	2026-08-24 21:18:00 +00:00