mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-13 14:32:03 +00:00
Deleting an account, a guardian deleting a managed profile, and "Delete
all data" were final the moment they were confirmed: the account row
cascaded into every table and every stored copy, and the off-host objects
were purged in the same breath. Nothing short of rolling the whole
instance back could return one account.
ACCOUNT_DELETION_GRACE_DAYS (14 by default, at most 30, 0 erases at once
as before) now sets a window:
- Account and managed-profile deletion lock the account (migration 0488:
deletion_requested_at, deletion_purge_at, deletion_requested_by_id).
Every session, refresh token, API token, connector, share link and
step-up elevation is revoked in the same transaction, and the record,
its stored copies and its off-host objects are left as they are.
- Sign-in is refused with 403 auth.account.deletion_pending and the
erasure date, after the credential was proved and before a second
factor is asked for. The session and Bearer resolvers and the acting-
account resolver refuse a pending account too, so a credential minted
in the moment before the lock is useless.
- POST /api/admin/users/{id}/undo-deletion (cookie-only, audit-logged)
clears the lock. The admin users list reports the pending state.
- The hourly account-deletion-purge job erases accounts whose window has
ended, exactly as the immediate deletion did, with the off-host purge
request committed alongside. The Guardian invariant is decided again;
a refused erasure stays pending and is reported.
- A wipe first stores the whole record as a PRE_WIPE_<ms> copy through
the writer the weekly copy uses, keeps it out of the wipe, and holds
its off-host purge back with a new not_before on the request. The
ordinary restore brings the record back; restoring that copy withdraws
the held purge. The purge job deletes the copy when its window ends.
Background work skips accounts pending deletion through one shared
predicate (src/lib/account-deletion/active-account.ts): every reminder,
digest, Coach, sync, backfill, rollup, score and backup enumeration
filters with it, and account-deletion-enumeration-guard.test.ts fails on
a query in background work that neither filters nor says why it need
not. Notification delivery and the AI capability loader refuse a pending
account as chokepoints behind it, and the Withings, WHOOP and Telegram
webhooks and the notification quick actions ignore one.
The privacy summary publishes the window. Two pieces of the reminder tick
and the off-host pass moved into modules of their own to keep the files
inside their size ratchet.
33 lines
1.4 KiB
SQL
33 lines
1.4 KiB
SQL
-- Account deletion, data wipe and managed-profile deletion keep the record
|
|
-- for a grace window before anything is erased.
|
|
--
|
|
-- `users.deletion_requested_at` marks an account as pending deletion: it is
|
|
-- locked at once and skipped by every background pass, and an admin can undo
|
|
-- the deletion until `deletion_purge_at`, when the purge job erases it the
|
|
-- way the immediate deletion did before. `deletion_requested_by_id` names who
|
|
-- asked (the account itself or a Guardian), as a plain id.
|
|
--
|
|
-- `offhost_purge_requests.not_before` lets a data wipe write its request
|
|
-- with the window's end, so the off-host copies from before the wipe stay
|
|
-- until then.
|
|
--
|
|
-- Nullable, no default, no backfill: no existing account is pending deletion
|
|
-- and every existing request is due now. Reversibility: dropping the columns
|
|
-- and the index restores the immediate behaviour's schema.
|
|
--
|
|
-- @retry-on-lock-timeout
|
|
|
|
DO $migration$
|
|
BEGIN
|
|
PERFORM set_config('lock_timeout', '5s', true);
|
|
ALTER TABLE "users"
|
|
ADD COLUMN IF NOT EXISTS "deletion_requested_at" TIMESTAMP(3),
|
|
ADD COLUMN IF NOT EXISTS "deletion_purge_at" TIMESTAMP(3),
|
|
ADD COLUMN IF NOT EXISTS "deletion_requested_by_id" TEXT;
|
|
ALTER TABLE "offhost_purge_requests"
|
|
ADD COLUMN IF NOT EXISTS "not_before" TIMESTAMP(3);
|
|
CREATE INDEX IF NOT EXISTS "users_deletion_purge_at_idx"
|
|
ON "users" ("deletion_purge_at");
|
|
END
|
|
$migration$;
|