mirror of
https://github.com/Donkie/Spoolman.git
synced 2026-10-22 01:52:17 -05:00
Donkie
404b03173b
Rotating deletes the oldest restore point and shifts the rest down, so enough calls in quick succession leave nothing but snapshots of whatever state the database is in now. POST /backup takes no parameters, so a bodyless cross-origin form post reached it; the audit destroyed a full six-deep history that way (todo.md task 2). The origin guard from the previous commit already refuses that request, but the rotation itself should not be this easy to abuse, so two further changes: Rotation is skipped when the database has not actually changed. Not by comparing the live database file, which the audit suggested: under WAL the live file does not yet contain recent commits, so comparing it would skip backups that were genuinely needed. Instead the snapshot is written to a pending file first and compared against the newest backup -- sqlite's backup API reads through the connection, so it sees WAL content. Identical means the pending file is discarded and the history is left alone. This is fail-safe: if the comparison ever came out unequal for an unchanged database, the result is the old behaviour of rotating, never a missed backup. Rotation is also rate-limited to one per five minutes, returning the newest existing backup instead. Never applied when there is no backup to fall back on. BackupResponse gained a `created` field so a client can tell the difference. Additive, so v1-compatible, but load-bearing: telling a user they have a fresh restore point when they do not is exactly the wrong failure mode here. Verified against a real server -- six rapid calls now leave exactly one backup and never rotate.