Drop the calendar's legacy authentication path
Step 5, the last one, of docs/calendar-auth-migration.md. Step 4 is deployed and verified, which is what this was waiting on: it removes the fallbacks that step 4 still leaned on. Gone: src/models/calendar/users/ entirely - registration, login, activation, both password-reset routes, and the session checking that the feedback and tickets admin areas used to authenticate against - along with its mount. That was the API's last unauthenticated account-creation and mail-sending endpoint. A survey confirmed nothing outside that directory imported it and nothing else touched its tables. Also gone: the two joins against the calendar users table in events.service.ts and the created_by_id / version_created_by_id columns they read, from the SQL, the row mapper, the Event interface and the swagger schema; and X-Session-Id / X-Session-Key from the CORS allowedHeaders, which nothing has read since the first cutover and nothing has sent since the second. An event's author still renders, because migration 002 snapshotted the names before this could erase them. That was brought forward from this step on purpose, and it is the reason 004 can rename the accounts aside at all. The accounts are renamed rather than dropped - they still hold e-mail addresses and password hashes, and a rename makes them unreachable without destroying anything. InnoDB rewires the sessions foreign key to the new name; verified on MariaDB 11, along with the whole 001-004 chain from the pre-cutover production schema, which lands byte-identical to a fresh dev database. Migration 004 must be applied AFTER deploying, not before - the reverse of step 4, whose migration only added things. Its own header and the runbook both say so, since getting it wrong by analogy is the obvious mistake. DEFERRED_SECURITY.md items 3 and 4 close with it: the activation and reset tokens that never expired are gone along with the code that issued them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -1,13 +1,13 @@
|
||||
# Migrating the Calendar domain onto the admin identity module
|
||||
|
||||
Status: **steps 1-4 implemented 2026-09-06, not yet merged or deployed.** Step 2 dropped by
|
||||
decision, part of step 5 brought forward. Only step 5, the removal of the legacy path, is
|
||||
left to write.
|
||||
Status: **complete.** Steps 1, 3 and 4 were deployed and verified in production on
|
||||
2026-09-06; step 2 was dropped by decision and part of step 5 brought forward. Step 5 is
|
||||
implemented and awaiting deploy - see its own checklist below, whose ordering is the
|
||||
**opposite** of step 4's.
|
||||
|
||||
> Read the deploy checklist under step 4 before applying anything. "Done" below means the
|
||||
> code exists on a branch, **not** that production has it - and in particular production has
|
||||
> none of the three migrations. Step 5 is scoped but deliberately unstarted: it must not be
|
||||
> built on top of a step 4 that has not been deployed and watched.
|
||||
Verified live after step 4: the public calendar still answers anonymously, all 23 public
|
||||
events kept a resolvable author, restricted calendars still refuse without a credential,
|
||||
legacy query credentials answer 401, and `calendar.nachklang.art` is trusted for sign-out.
|
||||
|
||||
Written 2026-09-05 alongside the admin module (step 2 of `docs/plan-admin-auth.md` in the
|
||||
nachklang-admin repo), which deliberately left the calendar alone. Steps 1-4 of that plan
|
||||
@@ -157,62 +157,57 @@ Each step is meant to leave production working on its own.
|
||||
|
||||
**One-way door:** any iCal subscription whose URL carries `?sessionId=&sessionKey=` rather
|
||||
than `?password=` stops working permanently. The shared-password URLs are unaffected.
|
||||
5. **Drop the legacy path.** Not started - and deliberately not started until step 4 has been
|
||||
deployed and watched, because it removes the fallback step 4 still leans on. Scoped and
|
||||
decided 2026-09-06; what follows is the agreed shape, not a suggestion.
|
||||
5. **Drop the legacy path.** **Implemented 2026-09-06** on `feature/calendar-drop-legacy-path`;
|
||||
not yet deployed. Gated on step 4 being live, which it now is.
|
||||
|
||||
**Prerequisite: step 4 live in production and behaving.** Until then the legacy join is
|
||||
what renders the author of every pre-cutover event, and the legacy routes are what an old
|
||||
cached bundle talks to. Doing this first turns a recoverable deploy into an unrecoverable
|
||||
one.
|
||||
What went:
|
||||
|
||||
Code, in one branch:
|
||||
- `src/models/calendar/users/` in its entirety - registration, login, activation, both
|
||||
password-reset routes, and the session checking the feedback and tickets admin areas
|
||||
used to authenticate against - plus its mount in `Calendar.router.ts`. That was the
|
||||
API's last unauthenticated account-creation and mail-sending endpoint.
|
||||
- The two `LEFT OUTER JOIN users` clauses in `events.service.ts` and the `legacy_*`
|
||||
aliases they fed, along with `created_by_id` / `version_created_by_id` in the SELECT, the
|
||||
row mapper and the `Event` interface. One name source remains besides the live admin
|
||||
lookup: the snapshot, which is what made this safe.
|
||||
- `X-Session-Id` / `X-Session-Key` from the CORS `allowedHeaders`. Nothing had read them
|
||||
since the tickets and feedback cutover, or sent them since this one.
|
||||
- The tripwire in `test/admin/auth-binding.ts` asserting neither module fell back to a
|
||||
calendar header session. There is nothing left to fall back to.
|
||||
|
||||
- **Delete `src/models/calendar/users/` entirely** - `users.router.ts`, `users.service.ts`,
|
||||
`session.interface.ts`, `user.interface.ts` - and the `calendarRouter.use('/users', ...)`
|
||||
line in `Calendar.router.ts`. *(Decided: delete outright rather than unmount.)* This
|
||||
removes the last unauthenticated account-creation and mail-sending endpoint in the API.
|
||||
A survey on 2026-09-06 confirmed nothing outside that directory imports it, and nothing
|
||||
outside it touches the `users`/`sessions` tables except the two joins below.
|
||||
- **Drop the legacy half of the read** in `events.service.ts`: the two
|
||||
`LEFT OUTER JOIN users` clauses, the `legacy_*` aliases, and `created_by_id` /
|
||||
`version_created_by_id` from the SELECT and the row mapper. The snapshot fallback stays -
|
||||
it is what makes this safe. Remove `createdById` / `lastModifiedById` from
|
||||
`event.interface.ts` and their (already deprecated) swagger properties.
|
||||
- **Remove `X-Session-Id` / `X-Session-Key`** from the CORS `allowedHeaders` in
|
||||
`src/app.factory.ts`. Nothing has sent them since the tickets and feedback frontends were
|
||||
redeployed.
|
||||
- **Drop the obsolete test mocks**: `test/feedback/feedback.auth.test.ts`,
|
||||
`test/tickets/tickets.auth.test.ts` and `test/admin/auth-binding.ts` each mock
|
||||
`calendar/users/users.service.js` and assert `checkSession` is never called. That
|
||||
tripwire is meaningless once the module does not exist; remove the mock and the
|
||||
assertion, keep the rest.
|
||||
`DEFERRED_SECURITY.md` items **3** and **4** (activation and reset tokens never expiring)
|
||||
close with it - not by adding expiries but by deleting the code that issued them.
|
||||
|
||||
Database, as `sql/calendar/004_*.sql`:
|
||||
### Deploy checklist — note the order is REVERSED from step 4
|
||||
|
||||
- Drop the foreign keys `events_users_user_id_fk` and `event_versions_users_user_id_fk`,
|
||||
then the `created_by_id` and `version_created_by_id` columns.
|
||||
- **`RENAME TABLE users TO users_legacy_archive`**, same for `sessions`. *(Decided: rename
|
||||
rather than drop.)* The reasoning: the display names are already snapshotted so nothing
|
||||
visible depends on these rows, but they still hold the old e-mail addresses and password
|
||||
hashes, and a rename makes the tables unreachable without destroying anything. Dropping
|
||||
them later is one statement, at a moment when nobody is mid-deploy.
|
||||
- Mirror all of it in `docker/init/01-calendar-schema-dev.sql` (the archive tables need no
|
||||
mirror - a fresh dev database has nothing to archive).
|
||||
Step 4's migration only added columns, so it went first. `004` *removes* columns and a
|
||||
table that the currently running build still selects and joins, so running it first fails
|
||||
every calendar read including the public feed. The step 5 build references none of them and
|
||||
runs happily against the old schema. Therefore:
|
||||
|
||||
Documentation: `DEFERRED_SECURITY.md` items **3** (activation token has no expiry) and
|
||||
**4** (password reset token has no expiry) close outright - both describe code that ceases
|
||||
to exist. Item 2 (no event ownership check) stays open.
|
||||
1. **Confirm the snapshot is complete.** Both must return 0:
|
||||
```sql
|
||||
SELECT SUM(created_by_id IS NOT NULL AND created_by_name IS NULL) FROM events;
|
||||
SELECT SUM(version_created_by_id IS NOT NULL AND version_created_by_name IS NULL) FROM event_versions;
|
||||
```
|
||||
A non-zero count is an event whose author `004` would erase. Re-run 002's backfill first.
|
||||
2. **Deploy the API.** No frontend deploy is needed: the calendar frontend never read
|
||||
`createdById` (its `Event` model has only the name), and nothing else is known to.
|
||||
3. **Confirm the calendar still works** - the public feed, a signed-in read, and one save.
|
||||
At this point the old columns and tables still exist, unused, so this step is fully
|
||||
reversible by redeploying the previous build.
|
||||
|
||||
Two consequences to accept explicitly rather than discover:
|
||||
Note that `tsc` does not remove output for deleted sources, so a build over an existing
|
||||
`dist/` leaves `dist/src/models/calendar/users/*.js` behind. Nothing imports it and the
|
||||
routes 404, but the deployed artifact still contains the code - clear `dist/` in the
|
||||
pipeline if you want the artifact to match the source.
|
||||
4. **Apply `sql/calendar/004_drop_legacy_auth.sql`.** This is the point of no return for
|
||||
the columns; the accounts themselves are only renamed aside.
|
||||
5. Optionally, later and at a quiet moment:
|
||||
`DROP TABLE sessions_legacy_archive, users_legacy_archive;`
|
||||
|
||||
- Any activation or password-reset e-mail already sent points at
|
||||
`api.nachklang.art/calendar/users/activate` and becomes a 404. Those links were only ever
|
||||
valid for legacy accounts, which no longer open anything.
|
||||
- `Event.createdById` disappears from the API response. The Angular frontend never read it
|
||||
(its `Event` model has only `createdBy`, the name), so this is not a breaking change for
|
||||
the only known consumer - but it is a wire-format removal, so check anything else that
|
||||
reads `/calendar/events/*/json` first.
|
||||
**One-way door:** `Event.createdById` and `lastModifiedById` leave the API response. Check
|
||||
anything reading `/calendar/events/*/json` that is not the calendar frontend.
|
||||
|
||||
## What the code actually looks like (surveyed 2026-09-06)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user