The maintenance-page reset used to rotate auth_code immediately. Because the
token also guards the playlist endpoints, that stopped a player from syncing
content the instant the button was pressed -- before the player ever had a
chance to react -- and clients that do not understand the heartbeat's
401 auth_required would have stayed broken until redeployed.
Split the model behaviour:
* request_reauth() -- sets the flag only (used by the admin reset endpoints
and the automatic interval). The current token stays valid, so there is no
outage while the player is being asked to re-authenticate.
* issue_new_token() -- replaces the token now (used by the existing
"regenerate auth code" action, where the admin is shown the new value).
* mark_authenticated() -- if a reset was pending, this is where the old token
is retired: a new token is issued and returned to the player in the
/api/auth/player response.
Net effect: the reset is a request the player acts on, never a forced logout.
A player that ignores it keeps working and shows as "awaiting re-auth" in the
UI; one that handles it gets a fresh token and the old one stops working.
Maintenance page wording updated to match (request vs reset; "awaiting
re-auth" badge), plus a themed info note explaining it is not a forced logout.
Adds docs/player-auth-reset.md describing the protocol and exactly what the
player client (Kiwy-Signage) still needs to implement: detect 401 /
auth_required on the heartbeat (and on the token-guarded endpoints), re-run
POST /api/auth/player with the stored quick-connect code, save the new
auth_code and retry. No password or SSH redeploy required.
Verified end-to-end: token unchanged and still accepted after the request
(200), heartbeat answers 401 auth_required=token_reset, re-auth issues a
different token, the old token is then rejected (403) and the new one accepted
(200), flag cleared; the interval path only flags without rotating.
Both bugs had the same cause: light colours were set with inline style
attributes, which outrank the theme rules in base.html and so survived the
dark theme. Text that inherits --text-color then became light-on-light.
* manage_player.html: the delete confirmation modal used an inline
background-color of #fefefe with the body's dark-mode text colour, making
the message unreadable in dark mode. Rebuilt it with .modal-* classes
driven by the base.html CSS variables (and dark-mode variants for the
title, warning and player name).
* admin/maintenance.html: the "Automatic reset interval" panel, table
headers and JS-rendered rows/tables hardcoded #f8f9fa/#e2e8f0/#dee2e6.
Switched them to --bg-color / --card-bg / --border-color /
--text-secondary and added a themed .maint-badge-pending.
Verified with computed styles in both themes; light mode is unchanged.
Admin-only page reachable from a new card on the admin panel (replacing the
Quick Actions card) that centralises housekeeping operations:
* Database integrity: PRAGMA integrity_check / quick_check / foreign_key_check,
plus VACUUM + ANALYZE to reclaim free space.
* Leftover records: detects and removes orphaned rows left behind by deleted
players/content (player_feedback, player_edit, playlist_content, dangling
player.playlist_id) and orphaned edited-media folders on disk.
* Player authentication tokens: manual reset (single or all), a configurable
automatic reset interval, and cancellation of a pending reset.
Resetting a token rotates player.auth_code and sets auth_reset_required, so the
next heartbeat (POST /api/player-feedback) answers 401 + auth_required and the
client restarts its authentication flow. A successful authentication clears the
flag and stamps auth_token_issued_at, from which the interval is measured.
New: PlayerAuthConfig model, add_player_auth_reset migration (registered in
docker-entrypoint.sh), admin/maintenance.html.
ske087