Archive/screentinker

Fork 0

mirror of https://github.com/screentinker/screentinker.git synced 2026-08-14 06:16:20 -06:00

Commit graph

Author SHA1 Message Date

Author	SHA1	Message	Date
screentinker	51b0b006b1	fix(pairing): reinstalled panel reclaims its device row instead of being blocked [Bold] (#180 ) Bold Media Group's fleet broke on the 1.9.3->1.9.6 upgrade. Their MDM does an uninstall/reinstall (app data wiped), so the player registers with { pairing_code, fingerprint } and NO device_id and shows a pairing code — but the dashboard reported "code does not exist". Deleting the device_fingerprints row fixed it, which pinpointed the fingerprint-reclaim guard in server/ws/deviceSocket.js. Root cause: the reclaim guard was `stillAlive = !!liveConn \|\| secondsSince < reclaimSettleSeconds; if (stillAlive) reject`. On an in-place reinstall the old row heartbeat seconds ago, so `secondsSince < 300` is ALWAYS true -> it emitted device:auth-error and returned BEFORE the pairing_code INSERT, so the code the player displayed never existed server-side. The settle window's real purpose was to REMATCH an existing fingerprint back to its device row on reinstall — not to force a fresh re-pair. So the fix keys off claim status, not the timer (server-only; no APK change — reviewed and confirmed unnecessary): - Reject ONLY when the old row has a genuinely LIVE socket (liveConn) — the real anti- hijack boundary. Unchanged. - CLAIMED old row (user_id set) -> RECLAIM it regardless of the settle window: reuse the row, rotate the token, emit device:registered{online} + device:paired. The panel returns straight to paired (no operator re-pair, no orphaned duplicate row), preserving name / claim / playlist / content. device:paired drives the app off the pairing screen, so the fresh code it showed is irrelevant. - UNCLAIMED old row -> fall through to the pairing_code path and PROVISION FRESH with the shown code (reclaiming would leave a stale/null code -> "code does not exist"). #150 relinks the fingerprint to the new row. `reclaimSettleSeconds` is now vestigial for this path. Trade-off: a fingerprint-only reclaim of a CLAIMED-but-offline device is no longer delayed ~300s — not a new attack class (the old code already granted it once the window elapsed); liveConn remains the hard boundary. Truly closing that window without a re-pair needs client keystore attestation (a future APK). Also fixes a latent crash this newly exercises: middleware/subscription.js getUserPlan() dereferenced an undefined user in its else branch ("Cannot set properties of undefined (setting 'trial_active')") when the user/plan JOIN missed. Under the claimed-reclaim path that ran checkDeviceAccess->getUserPlan, the throw was swallowed by the reclaim try/catch and silently dropped the device to provision-fresh. Guard: `if (!user) return null`. Tests (server/test/fingerprint-reclaim.test.js): - NEW: a CLAIMED reinstall reclaims the SAME row, emits device:paired, creates no duplicate, keeps the fingerprint linked — regardless of the settle window (the Bold repro, fixed right). - NEW: recent heartbeat + no live socket, UNCLAIMED -> provisions fresh with the shown code. - NEW: a LIVE old socket still rejects and creates no new row (security preserved). - Updated the #143 gone-device test to expect provision-fresh for an unclaimed row, and the log-noise assertion to the "reclaim rejected" message. 465/465 server tests pass. Server-only: NOT deployed, no version bump, Android untouched. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 23:07:50 -05:00
screentinker	12c0004245	test(ci): OS-assigned ephemeral ports for subprocess suites — kill the port-collision flake (#176 ) The subprocess-booting test suites hand-picked fixed ports in a cramped ~3955-4021 range, and 156-schedule-read-path deviated to a RANDOM port (3900 + rand%90) that overlapped those fixed ports. Under CI load two servers could race on the same port, surfacing as flaky "no such table: devices" / "FOREIGN KEY constraint failed" (a server answering a request against a half-migrated or wrong DB). It's environmental — the suites pass locally and in isolation. Fix: a shared test/helpers/free-port.js (bind :0 on loopback, read the OS-assigned port, release) called in before() so every suite gets a guaranteed-unique ephemeral port — concurrent suites can no longer collide, and no one has to hand-assign ports. - Codemod converted 30 suites: const PORT = <fixed\|random> -> let PORT (+ BASE) assigned via `PORT = await freePort()` at the top of before(). - 3 hand-fixed (different structure): 148-eviction-storm (lowercase `base`), boot-health (no before() — allocates PORT + a throwaway SEED_PORT inside the test, replacing the hardcoded 3894), totp-keyrotation (no before() — allocates at the test start before bootServer()). No fixed 39xx/40xx ports remain. Full server suite 435/435; the 4 hand-touched suites pass in isolation. Pure test-infra change — no app code touched.	2026-07-13 09:51:40 -05:00
ScreenTinker	e73428182d	fix(#143 ): fingerprint-reclaim stuck loop — reclaim by runtime liveness, throttle log Bold beta1: three devices spam "Fingerprint reclaim rejected ... device active (status=offline, ~2500s since heartbeat, liveConn=false)" twice/~2s indefinitely — contradictory: gone by every signal yet treated as active. Root cause (NOT a missing clear — corrected the hypothesis). The reject condition was `liveConn \|\| status==='online' \|\| secondsSince < RECLAIM_GRACE_SECONDS(24h)`. For the observed devices liveConn=false and status=offline, so the ONLY true term is `secondsSince < 24h` — an effective 24h CALENDAR grace, not a stale flag. Audited the clears: liveConn (deviceConnections) is removed on the debounced disconnect (heartbeat.removeConnection) AND the offline_timeout sweep (deviceConnections.delete); status is set 'offline' on both. liveConn=false + status=offline PROVE the clears ran — there is nothing stale to clear. The 24h time gate (mislabeled "device active") blocked a legitimately-gone device from reclaiming for up to 24h, so it retried every ~2s forever-in-practice. The "twice per ~2s" is two reclaim ATTEMPTS per cycle (client reconnect + re-pair-on-auth-error), each hitting the single console.warn — not double-logging in one attempt. Fix: - Decide "still alive" from RUNTIME signals: `!!liveConn \|\| secondsSince < reclaimSettleSeconds`. A device with no live socket and a heartbeat older than the settle window is gone -> reclaimable. A live (or just-seen) device is still rejected, so reclaim-abuse protection holds. NOT just ignoring "active" — it fixes WHY it was stuck (the 24h gate). RECLAIM_SETTLE_SECONDS default 300 (was 24h). SECURITY TRADEOFF flagged in config: shortens the anti-fingerprint-theft window; raise to re-tighten. Tuning guess to validate vs Bold. - Log throttle: the deferral logs at most once per device per RECLAIM_REJECT_LOG_ WINDOW_MS (default 60s) — collapses the double-log + the per-2s flood (same discipline as the content-ack shed log). Cleared when a reclaim proceeds. Recovery of the 3 wedged devices (2febcaa9, 1984694c, 139159eb): they SELF-HEAL on their next reclaim attempt (~2s) once this ships — their heartbeats are ~2500s stale (>300s settle) and liveConn=false, so the reclaim now succeeds. No operator SQL needed. Tests (port 3988): gone device reclaims; live device still rejected; clear-on-leave (disconnect clears liveConn -> stale device reclaims); deferral log <=1 per window. Full suite green serial+parallel (217). reconnect-throttle.js, the `dbac699` content-ack limiter, and the `404c330` block/auth code untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-27 22:56:48 -05:00

screentinker

51b0b006b1

fix(pairing): reinstalled panel reclaims its device row instead of being blocked [Bold] (#180 )

Bold Media Group's fleet broke on the 1.9.3->1.9.6 upgrade. Their MDM does an
uninstall/reinstall (app data wiped), so the player registers with
{ pairing_code, fingerprint } and NO device_id and shows a pairing code — but the
dashboard reported "code does not exist". Deleting the device_fingerprints row fixed
it, which pinpointed the fingerprint-reclaim guard in server/ws/deviceSocket.js.

Root cause: the reclaim guard was
`stillAlive = !!liveConn || secondsSince < reclaimSettleSeconds; if (stillAlive) reject`.
On an in-place reinstall the old row heartbeat seconds ago, so `secondsSince < 300` is
ALWAYS true -> it emitted device:auth-error and returned BEFORE the pairing_code INSERT,
so the code the player displayed never existed server-side.

The settle window's real purpose was to REMATCH an existing fingerprint back to its
device row on reinstall — not to force a fresh re-pair. So the fix keys off claim status,
not the timer (server-only; no APK change — reviewed and confirmed unnecessary):
- Reject ONLY when the old row has a genuinely LIVE socket (liveConn) — the real anti-
  hijack boundary. Unchanged.
- CLAIMED old row (user_id set) -> RECLAIM it regardless of the settle window: reuse the
  row, rotate the token, emit device:registered{online} + device:paired. The panel returns
  straight to paired (no operator re-pair, no orphaned duplicate row), preserving name /
  claim / playlist / content. device:paired drives the app off the pairing screen, so the
  fresh code it showed is irrelevant.
- UNCLAIMED old row -> fall through to the pairing_code path and PROVISION FRESH with the
  shown code (reclaiming would leave a stale/null code -> "code does not exist"). #150
  relinks the fingerprint to the new row.
`reclaimSettleSeconds` is now vestigial for this path. Trade-off: a fingerprint-only reclaim
of a CLAIMED-but-offline device is no longer delayed ~300s — not a new attack class (the old
code already granted it once the window elapsed); liveConn remains the hard boundary. Truly
closing that window without a re-pair needs client keystore attestation (a future APK).

Also fixes a latent crash this newly exercises: middleware/subscription.js getUserPlan()
dereferenced an undefined user in its else branch ("Cannot set properties of undefined
(setting 'trial_active')") when the user/plan JOIN missed. Under the claimed-reclaim path
that ran checkDeviceAccess->getUserPlan, the throw was swallowed by the reclaim try/catch and
silently dropped the device to provision-fresh. Guard: `if (!user) return null`.

Tests (server/test/fingerprint-reclaim.test.js):
- NEW: a CLAIMED reinstall reclaims the SAME row, emits device:paired, creates no duplicate,
  keeps the fingerprint linked — regardless of the settle window (the Bold repro, fixed right).
- NEW: recent heartbeat + no live socket, UNCLAIMED -> provisions fresh with the shown code.
- NEW: a LIVE old socket still rejects and creates no new row (security preserved).
- Updated the #143 gone-device test to expect provision-fresh for an unclaimed row, and the
  log-noise assertion to the "reclaim rejected" message.
465/465 server tests pass. Server-only: NOT deployed, no version bump, Android untouched.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-13 23:07:50 -05:00

screentinker

12c0004245

test(ci): OS-assigned ephemeral ports for subprocess suites — kill the port-collision flake (#176 )

The subprocess-booting test suites hand-picked fixed ports in a cramped ~3955-4021 range, and
156-schedule-read-path deviated to a RANDOM port (3900 + rand%90) that overlapped those fixed
ports. Under CI load two servers could race on the same port, surfacing as flaky "no such table:
devices" / "FOREIGN KEY constraint failed" (a server answering a request against a half-migrated
or wrong DB). It's environmental — the suites pass locally and in isolation.

Fix: a shared test/helpers/free-port.js (bind :0 on loopback, read the OS-assigned port, release)
called in before() so every suite gets a guaranteed-unique ephemeral port — concurrent suites can
no longer collide, and no one has to hand-assign ports.

- Codemod converted 30 suites: const PORT = <fixed|random> -> let PORT (+ BASE) assigned via
  `PORT = await freePort()` at the top of before().
- 3 hand-fixed (different structure): 148-eviction-storm (lowercase `base`), boot-health (no
  before() — allocates PORT + a throwaway SEED_PORT inside the test, replacing the hardcoded
  3894), totp-keyrotation (no before() — allocates at the test start before bootServer()).

No fixed 39xx/40xx ports remain. Full server suite 435/435; the 4 hand-touched suites pass in
isolation. Pure test-infra change — no app code touched.

2026-07-13 09:51:40 -05:00

ScreenTinker

e73428182d

fix(#143 ): fingerprint-reclaim stuck loop — reclaim by runtime liveness, throttle log

Bold beta1: three devices spam "Fingerprint reclaim rejected ... device active
(status=offline, ~2500s since heartbeat, liveConn=false)" twice/~2s indefinitely —
contradictory: gone by every signal yet treated as active.

Root cause (NOT a missing clear — corrected the hypothesis). The reject condition
was `liveConn || status==='online' || secondsSince < RECLAIM_GRACE_SECONDS(24h)`.
For the observed devices liveConn=false and status=offline, so the ONLY true term
is `secondsSince < 24h` — an effective 24h CALENDAR grace, not a stale flag. Audited
the clears: liveConn (deviceConnections) is removed on the debounced disconnect
(heartbeat.removeConnection) AND the offline_timeout sweep (deviceConnections.delete);
status is set 'offline' on both. liveConn=false + status=offline PROVE the clears
ran — there is nothing stale to clear. The 24h time gate (mislabeled "device active")
blocked a legitimately-gone device from reclaiming for up to 24h, so it retried
every ~2s forever-in-practice. The "twice per ~2s" is two reclaim ATTEMPTS per cycle
(client reconnect + re-pair-on-auth-error), each hitting the single console.warn —
not double-logging in one attempt.

Fix:
- Decide "still alive" from RUNTIME signals: `!!liveConn || secondsSince <
  reclaimSettleSeconds`. A device with no live socket and a heartbeat older than the
  settle window is gone -> reclaimable. A live (or just-seen) device is still
  rejected, so reclaim-abuse protection holds. NOT just ignoring "active" — it fixes
  WHY it was stuck (the 24h gate). RECLAIM_SETTLE_SECONDS default 300 (was 24h).
  SECURITY TRADEOFF flagged in config: shortens the anti-fingerprint-theft window;
  raise to re-tighten. Tuning guess to validate vs Bold.
- Log throttle: the deferral logs at most once per device per RECLAIM_REJECT_LOG_
  WINDOW_MS (default 60s) — collapses the double-log + the per-2s flood (same
  discipline as the content-ack shed log). Cleared when a reclaim proceeds.

Recovery of the 3 wedged devices (2febcaa9, 1984694c, 139159eb): they SELF-HEAL on
their next reclaim attempt (~2s) once this ships — their heartbeats are ~2500s stale
(>300s settle) and liveConn=false, so the reclaim now succeeds. No operator SQL needed.

Tests (port 3988): gone device reclaims; live device still rejected; clear-on-leave
(disconnect clears liveConn -> stale device reclaims); deferral log <=1 per window.
Full suite green serial+parallel (217). reconnect-throttle.js, the dbac699 content-ack
limiter, and the 404c330 block/auth code untouched.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-27 22:56:48 -05:00

3 commits