mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-19 13:36:48 +00:00
Maurice
474beb0dfb
Both swap the whole database file. The demo reset copies a baseline saved at first seed, before anyone logged in, so it brings back an empty user_sessions table; a backup restore brings the backup's own rows, or none for a backup from before sessions were tracked. A session token whose row is missing is refused, so the hourly reset signed every demo visitor and the demo admin out, and the admin who ran a restore got a 401 on the next request. Before session tracking only the password version applied, and those tokens survived. Both paths now read the active rows with their owner's email before the swap and put them back after the reopen, in a fresh fork, for every account the new file still holds under the same id and email. A row the new file already has is left as it is, so a session that ended there stays ended, and a session whose id now names somebody else (a backup from another install) is dropped instead of handed to them. The password version check still refuses a token the restored account no longer matches. Reading or writing them is best effort and never fails the reset or the restore.