Paddy
aa95ab2745
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>
61 lines
3.0 KiB
SQL
61 lines
3.0 KiB
SQL
-- Nachklang e.V. Calendar module — step 5 of docs/calendar-auth-migration.md.
|
|
-- Apply manually against the CALENDAR_DB database, after 003:
|
|
-- mysql -h <DB_HOST> -u <DB_USER> -p <CALENDAR_DB> < 004_drop_legacy_auth.sql
|
|
--
|
|
-- *** APPLY THIS AFTER DEPLOYING THE API, NOT BEFORE. ***
|
|
--
|
|
-- This is the opposite order from the step 4 cutover, and getting it wrong by
|
|
-- analogy is the obvious mistake. Step 4's migration only *added* things, so it
|
|
-- was safe ahead of the deploy. This one removes columns and a table that the
|
|
-- currently running build still selects and joins - applying it first fails
|
|
-- every calendar read, including the anonymous public feed the website uses.
|
|
-- The step 5 build touches none of them, so it runs happily against the old
|
|
-- schema; deploy it, confirm the calendar works, then run this.
|
|
--
|
|
-- Nothing here loses information that is still reachable: the creators' display
|
|
-- names were snapshotted into events.created_by_name and
|
|
-- event_versions.version_created_by_name by migration 002, and the step 4
|
|
-- runbook re-ran that backfill after the deploy. Verify before running:
|
|
--
|
|
-- 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;
|
|
--
|
|
-- Both must be 0. A non-zero count is an event whose author this migration
|
|
-- would erase; re-run 002's backfill first.
|
|
|
|
-- The foreign keys have to go before the columns they are declared on.
|
|
-- IF EXISTS so that a re-run after a partial failure gets past them.
|
|
ALTER TABLE `events`
|
|
DROP FOREIGN KEY IF EXISTS `events_users_user_id_fk`;
|
|
|
|
ALTER TABLE `event_versions`
|
|
DROP FOREIGN KEY IF EXISTS `event_versions_users_user_id_fk`;
|
|
|
|
ALTER TABLE `events`
|
|
DROP INDEX IF EXISTS `events_users_user_id_fk`,
|
|
DROP COLUMN IF EXISTS `created_by_id`;
|
|
|
|
ALTER TABLE `event_versions`
|
|
DROP INDEX IF EXISTS `event_versions_users_user_id_fk`,
|
|
DROP COLUMN IF EXISTS `version_created_by_id`;
|
|
|
|
-- The accounts themselves are renamed aside rather than dropped.
|
|
--
|
|
-- Nothing visible depends on them any more - the names are snapshotted, and no
|
|
-- code has referenced these tables since the step 4 cutover. But they still
|
|
-- hold e-mail addresses and password hashes, and a rename makes them
|
|
-- unreachable without destroying anything.
|
|
--
|
|
-- `sessions` has a foreign key into `users`; InnoDB rewires it to the new name
|
|
-- on rename, so after this it reads REFERENCES `users_legacy_archive` and the
|
|
-- pair stays internally consistent whichever order they are renamed in.
|
|
-- Verified on MariaDB 11.
|
|
--
|
|
-- Unlike the statements above this is not re-runnable, and that is the safe
|
|
-- behaviour: a second run fails on a missing `sessions` rather than doing
|
|
-- anything. Drop them for real whenever you like, at a moment when nobody is
|
|
-- mid-deploy:
|
|
-- DROP TABLE `sessions_legacy_archive`, `users_legacy_archive`;
|
|
RENAME TABLE `sessions` TO `sessions_legacy_archive`;
|
|
RENAME TABLE `users` TO `users_legacy_archive`;
|