113 commits

Author	SHA1	Message	Date
screentinker	e9bd8ac8af	Opt-in install statistics (#267) ... There is no way to answer "how many screens run ScreenTinker?". The product is self-hostable by design, so most installs are invisible to us on purpose — and should stay that way. This asks once, and reports only if the operator says yes. The entire payload is three fields: { instance_id, version, screen_count } instance_id is a random UUID minted on first use and kept in app_settings. It carries nothing about the install; its only job is to let two reports from the same server be recognised as one server, so a count is a count rather than a sum of duplicates. That makes a report pseudonymous rather than anonymous, and the wording shown to operators says so rather than claiming otherwise. The payload is short on purpose. Every field added costs participation, and participation is the only thing that makes the resulting number worth quoting. Player-platform counts were considered and left out: release assets are already published per platform, so GitHub's per-asset download counts answer "where should effort go" at zero privacy cost and without asking anyone for anything. Verifiability is the feature, not the copy. Settings shows the ACTUAL payload this server would send, generated live from its own data, plus what it last really sent and when. The payload is built in one function so a reviewer can check it at a glance, and the test fails if a field is ever added. Both answers persist. Declining is remembered as 'off' rather than falling back to 'unasked', so the prompt cannot return after an update — re-prompting is how telemetry earns its reputation and gets patched out. Collector side is inert unless TELEMETRY_COLLECTOR=1, so a normal install never exposes the endpoint. Reports upsert on instance_id rather than appending, so an install reporting daily occupies one row rather than 365 a year. The source IP is never read or stored — receiving one is unavoidable, logging it would quietly turn a pseudonymous report into an identifiable one. Tests pin the negative promises, which are the ones that rot silently: sends nothing before consent, sends nothing after a decline, payload is exactly three keys, id survives a restart, a failed send never records a phantom report. Screen count excludes unpaired provisioning rows, which would otherwise overstate the one number this exists to state honestly. docs/telemetry.md documents the payload, what is not sent, how to verify it, and that any published total is a floor rather than a basis for extrapolation. 1657/1657 pass.	2026-08-13 17:27:10 -05:00
ScreenTinker	fbf55f842c	Close the third QA round: limiter bypass, stored XSS, break-glass, org placement ... Four HIGH findings. Two were mine, and one was a composition of two of my own fixes. ONE EXTRA SLASH DEFEATED EVERY /api/auth LIMITER `/api/auth//login` still reaches the login handler — Express normalises the mount boundary for the router — but `app.use('/api/auth/login', rateLimit(...))` does not match it, so the limiter never runs. A review got a real session after 60 unthrottled password attempts. Same for //totp/verify (unlimited 6-digit brute force), //forgot-password (unlimited reset mail to any address) and //sso/discover (the customer-enumeration cap, gone). Fixing the limiter KEY could never help, because the middleware was never invoked: the path is now collapsed to one canonical form before routing. Pre-existing, and it falsified this file's own warning about walking past the login limiter. STORED XSS: I ESCAPED ONE COPY OF THE TABLE My earlier fix patched views/admin.js line 357 and missed line 372 in the same function — and missed views/settings.js entirely, which renders a SECOND copy of the platform users table from the same endpoint, including the email in a raw text node. The write path was `POST /api/admin/users`, whose EMAIL_RE barred only whitespace, so an org or workspace admin (not a platform admin) could choose an address that executed in the operator's session. Both tables escaped, both regexes tightened to reject markup characters, verified against 11 address shapes. I KILLED THE BREAK-GLASS WHILE CLOSING AN ORACLE Hoisting the domain check above the account lookup — my fix for the enumeration oracle — made `user.role !== 'platform_admin'` unreachable for enforced domains. On a self-host the operator IS the org owner, and my would_lock_out_actor guard GUARANTEES their address is inside the enforced set, so the recovery loop closed on itself: approving a removal request needs a signed-in platform admin. Both properties hold now by letting the operator through on a CORRECT PASSWORD only — every wrong answer is the identical 403 whether the address exists, does not exist, or is theirs. Verified: 200 / 403 / 403 / 403. Also fixed: enabling SSO-only locked out every password-holding member including the admin who pressed the button (password refused by policy, SSO refused by account_exists_local). An org provider now adopts a password account at a domain it has PROVED by DNS when the org requires SSO — which is what a verified domain means, and what every hosted identity product does. SSO USERS WERE LANDING IN A PERSONAL ORG The membership write added organization_members but no workspace_members, and ensureDefaultOrgForUser looks at workspaces — so it minted each SSO user a private organization and made it their current one. The customer's Members page read "Members (1)" while their staff signed in successfully and were invisible. ALSO: bcrypt on a NULL password_hash 500'd with a stack (and was an oracle for accounts a provider deletion had returned to local); stranded_members was returned by the server and discarded by the UI; a provider with zero domains was the one useless state with no warning; two limiter shapes were missing (removal-request shared the garbage bucket — an unauthenticated flood could deny the SSO break-glass path); doubled mail subject prefixes; a DELETE that toasted "Saved"; a decided request left in the DOM with live listeners; and a confirm dialog promising "immediately" when sessions already open survive. 1609 tests, three clean runs. Limiter, break-glass, oracle parity and null-password all verified against a running server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-11 11:25:11 -05:00
ScreenTinker	85febe05c0	Fix a login-page dead end, an enumeration oracle, and three boot/limiter defects ... From the regression sweep. The first is a genuine regression against main. A RATE-LIMITED DISCOVERY PERMANENTLY DEAD-ENDED THE LOGIN PAGE lookupOrgSso checked that a body PARSED, not that the request succeeded — and a 429 body is valid JSON. So `data.sso` came back undefined, the single sign-on button was hidden, the password box restored, and the domain recorded as answered: permanently, for the life of the page. On an SSO-only domain that is the worst outcome available — the password box then returns 403 and the button the user is told to use is not on the screen. Discover is 10/min per IP and one person filling in the form costs up to four calls, so a few colleagues behind one office address is enough. The comment above that code already claimed to prevent exactly this; it only ever covered the 5xx case. THE SSO-ONLY REFUSAL WAS AN ACCOUNT-EXISTENCE ORACLE 403 for an address that exists, 401 for one that does not — from an endpoint whose own lockout returns 401 specifically to avoid that. The DOMAIN check now runs BEFORE the account lookup, so both answer identically; whether a domain uses single sign-on is already public through /sso/discover, so it reveals nothing new. The membership-level refusal is deliberately downgraded to the generic 401, because a distinct answer there would put the oracle back for exactly the accounts worth enumerating. Verified: existing and invented addresses at an SSO-only domain both 403; and on an instance with NO SSO configured, register/login/wrong-password/unknown-address are 201/200/401/401 — the hoisted check does not touch them. BOOT PREFLIGHT - a cold install ran `npm ci --omit=dev` unconditionally, so a first start on a developer machine left `npm test` broken: same class of surprise as the prune this file already warns about, through the other branch of the same if. Now production- only. - two servers starting together: the loser died with ENOTEMPTY even though the tree was complete by then. It re-checks before failing. - the opt-out accepted only '1', unlike every other boolean the server takes. THE LIMITER FOLD, DONE PROPERLY Unmatched paths under /api/organizations still minted a bucket each. My first fix was a catch-all regex — which put every unknown path in ONE bucket WITH the real endpoints, so flooding nonsense URLs exhausted the limit for /sso-only. That trades a bypass for a denial of service. Folding is now by explicit shape: known endpoints keep their own keys, everything else shares a bucket kept apart from all of them. Verified: 120 unmatched paths give 60/60 (bypass closed), and after that flood /sso-only, /sso and /sso/:id/test all still answer 401 rather than 429 (no starvation), while 70 hits on one real endpoint do trip its own limit. The login trailing-slash bypass stays closed. 1609 tests, three clean runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-11 10:22:25 -05:00
ScreenTinker	37e22bb773	SSO-only: enforce per-domain, cover invited members, and stop the admin locking themselves out ... A second attack round defeated three of the previous fixes and found a regression I introduced. Each is reproduced-then-refused against a live server. MEMBERSHIP: organization_members IS NOT HOW PEOPLE JOIN Only three places write that table and nothing deletes from it — every INVITED user, every admin-created account and every workspace assignment lands in workspace_members and nowhere else. So keying enforcement on organization_members covered org owners and people who had already used SSO: exactly the set the domain check already caught. A reviewer invited an outside address into an SSO-only tenant, kept password login, read the member list and content, and used it to invite more. Enforcement now asks whether the user is in ANY workspace belonging to an SSO-only organization. THE INTERLOCK ASKED THE WRONG QUESTION, TWICE It fired only when a domain list became EMPTY, and it counted PROVIDERS. So: - replacing acme.test with decoy.test removed every proof and sailed through — two PUTs, and the customer's domain enforced nothing, with sso_only still reading true; - with two providers you could disable the one owning your staff's domain, because the other one, covering a domain nobody signs in at, still "enforced". The question that matters is per-DOMAIN: after this change, is every domain that enforces today still enforcing? Losing one needs the operator, whichever route gets you there. The refusal now names the domain that would stop being covered. REGRESSION I CAUSED: THE HAPPY PATH LOCKED THE OWNER OUT Sign up with a personal address, create the org, verify the company domain, turn this on — and enforcement covers you (you are a member) while your own address is outside the verified domains, so passwords are refused AND your org's provider will not assert for you either. No route removes a membership; reset succeeds but login still refuses. Recovery meant a platform admin turning SSO off for the whole tenant. Enabling now refuses when the actor's own address is not covered, naming it, and REPORTS everyone else who will be stranded instead of letting them be discovered by support ticket. ALSO - POST /api/admin/users gated only on the target workspace, so you could mint cfo@theircompany.test into your OWN workspace: login refused, but the row now has a password_hash and an SSO login will not adopt one — permanently locking a real person out of their own address. Now gated on the address's domain too. - `ceo@acme.test.` (trailing root dot) slipped the registration gate. - two rate-limited sub-paths were still unfolded because the generic org-id fold ate `sso-only` as an organization id; the specific shapes are matched first now. 1609 tests, three clean runs. Verified live: invited outsider 403, swap refused, sibling-disable refused, squat 400, self-lockout refused with the address named, and an on-domain admin gets `stranded_members` back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-11 09:51:40 -05:00
ScreenTinker	355b7a2b86	SSO: build the operator approval screen, and close the last of the QA findings ... The approval workflow had no front door. The notification email told the operator to "review it in ScreenTinker under Admin" and that screen did not exist — the only way to approve was curl, while the tenant sat locked out of their own product. Admin now leads with a removal-request section: who asked, for which organization, the reason they gave, what approving does, and Approve/Reject. It hides itself when the queue is empty. Approving is confirmed; rejecting is not, because rejecting only leaves the safe state. REGISTRATION BYPASSED SSO-ONLY AND SQUATTED ADDRESSES /register had no domain awareness: it issued a working session at an SSO-only domain, and the account then held that address forever, because an SSO login will not adopt a row that has a password. Registering ceo@acme.test before the real CEO's first login left the address dead in both directions with no self-service way out. Refused now, and "Create Account" is hidden on the login page for those domains — it was the only action left on the card, so the page was inviting the one thing that cannot work. THE NEW RATE LIMIT WAS DECORATIVE /api/organizations carries three caller-chosen segments, and only the OIDC slug was folded — so every request minted its own bucket. Measured: 120 calls with unique org ids produced ZERO 429s, unauthenticated, against the limit that exists to bound outbound discovery and live DNS. Now 60/60. The general problem was named in the previous commit's own comment and then not applied to the mount it added. XSS IN THE TOAST showToast built innerHTML from server strings, including ones that reflect input verbatim — a reviewer typed `<img src=x onerror=alert(1)>` as an issuer and got script execution in the admin's session. Escaped. ALSO - the org SSO button sat BETWEEN the "Password" label and its input, so the label described the button and the field had none; moved below the input, with a for= - the OR divider survived when the providers under it were hidden - provider action buttons were clipped off-screen at 375px with no way to scroll to them — "Remove" was unreachable; the row wraps now 1609 tests. Verified in real Chrome: 13/13 on the approval loop and the login states, including approving a request and watching password login re-open for that org. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-11 08:48:53 -05:00
ScreenTinker	601b526264	Boot: install missing dependencies and rebuild the native module before starting ... scripts/upgrade.sh already runs `npm ci`, so this is not for the normal path. It is for the ways a box ends up with the wrong node_modules, both of which present as "server will not start" with an error naming a file rather than the action needed: ROLLBACK checking out an older tag to back out a bad release restores that tag's package.json but not its packages. This branch removes google-auth-library, so a rollback to main would not boot — and you are rolling back because something else already broke. NODE UPGRADE better-sqlite3 is compiled against one ABI. Upgrading Node makes every boot fail with NODE_MODULE_VERSION, which reads like database corruption and is not. Runs as the FIRST statement in server.js, before any dependency is required, and uses only Node builtins — anything it imported could be the thing that is missing. Repairs with `npm install --omit=dev` (never `ci` on a partly-populated tree, which would delete a working node_modules to fix one package) or `npm rebuild better-sqlite3`, and exits with the command to run if it cannot. ST_SKIP_DEP_PREFLIGHT=1 opts out. ⚠️ The first version of the native check was WRONG and I caught it only by running it under a real version mismatch: better-sqlite3's entry point is plain JavaScript that loads the compiled binding lazily, so `require()` succeeds under a Node the binary was never built for. It reported a genuinely broken install as healthy. It now opens an in-memory database, which is what actually pulls the binding in. A test pins that, because the failure is invisible — the check keeps passing on every machine where nothing is wrong. Verified: a deleted dependency is detected, installed and the server boots (200); the ABI mismatch is detected under Node 18 against a module built for Node 20 and reported clean under Node 20; a healthy tree costs 8ms and touches no network. 1609 tests pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 22:44:26 -05:00
ScreenTinker	c91b96ab91	SSO: refuse delegated proof names, release lapsed and deleted claims ... Third review pass. It confirmed the crash wrapper holds (~13,000 hostile requests, no fourth crash), the SSRF rewrite holds (77 vectors, every CIDR boundary proven), the rate-limiter rewrite closed the login brute-force bypass, and /sso/claim rejects every wrong token kind. It also found that two things I built yesterday did not do what they claimed. THE 8-HOUR LIMIT DID NOT BOUND SQUATTING Pressing Verify on an expired claim REISSUED it in place, renewing the clock — so one request per window held a domain forever, through the endpoint meant to enforce the limit. Worse, a renewal was not a new claim, so the operator was notified exactly once, on day zero: a tenant could sit on a company's domain for a year off a single stale alert. A lapsed claim is now RELEASED. Re-adding it is an ordinary new claim: new token, and the operator is told again. Squatting is not impossible; it is loud. A DELEGATED PROOF NAME COULD FORGE A DOMAIN A TXT lookup follows CNAMEs, and RFC 4592 means a wildcard `*.victim.com` synthesizes `_screentinker-verify.victim.com` too — so a wildcard CNAME let whoever controls its target prove a domain they do not own, turning an ordinary subdomain takeover into every `@victim.com` login. A reviewer did this against a real authoritative zone. The proof name is now refused if it is a CNAME, which is stricter than ACME's dns-01, and the comment that claimed wildcards "cannot be mistaken for a proof" — true only for wildcard TXT — has been corrected. MY VERIFY BUTTON REPORTED FAILURE ON SUCCESS `await load()` — the loader is `loadSso()`. The ReferenceError went into a bare catch, so a correct DNS proof showed "Could not verify that domain" and left the card stale. On the expired branch the admin kept publishing a token the server had already rotated. ALSO FIXED - deleting a provider stranded its verified domains (no FK, UNIQUE, never expires) so the domain was blocked for EVERY org forever with no in-product recovery, and its users could neither sign in nor reset. Delete now releases the domains and returns the accounts to local, in one transaction; a cascade FK backstops it. - isOrphanedFederated read absence-of-config as proof-of-deletion, so unsetting GOOGLE_CLIENT_ID made every Google account password-resettable instance-wide, and irreversibly. Restricted to org-provider slugs. - `email_domains: null` (not undefined) took the destructive branch and deleted every DNS proof an organization had. - unbounded domain lists: 400 domains sent 401 emails; now capped at 50, one digest per save, and /api/organizations is rate-limited at all for the first time. - login and register responses carried password_reset_hash and email_verify_hash — live account-takeover credentials handed to the browser. One sanitiser now. - trailing-dot hostname (`https://localhost./`) slipped the SSRF guard. - asyncRoute's own catch could throw and kill the process it exists to protect. - a legacy DB whose typed domains were never verified now says so LOUDLY at boot instead of silently locking every federated user out. TESTS Two of the previous round's tests passed against the code they were named after: one asserted UNIQUE against the test harness's own CREATE TABLE rather than the shipped schema, the other used two different domains so no ordering was exercised. Both replaced and confirmed load-bearing. Seven mutations now turn the suite red, including removing the CNAME refusal, the verified_at filter, and the expiry itself. 1598 tests pass. Delete-release, lapse-release and the leak fix verified against a running server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 21:01:26 -05:00
ScreenTinker	d4b8d7dad4	SSO: prove domain ownership by DNS, and fix what the second review found ... A second review pass, run against the previous commit, found four blockers — two of them introduced by the fixes in that commit. It also confirmed the original account takeover is closed: a hostile IdP with real TLS, discovery, JWKS and RS256 driving the real routers now stops at domain_not_allowed, and all 16 bypass variants are refused. DOMAIN OWNERSHIP (the root cause, not the symptom) A claimed domain used to mean "nobody else claimed it". It now means the organization published a record in that domain's own DNS — TXT or CNAME, at a dedicated _screentinker-verify name rather than the apex, where an edit would sit beside SPF. - an unverified domain routes NOBODY and cannot be asserted; it reserves the name - an unverified claim LAPSES after 8 hours, so a domain cannot be held against its real owner, and lapsing rotates the token so a record left over from an abandoned attempt cannot satisfy a later claim - a verified domain never expires — re-proving on a timer would log a customer out over a DNS edit made months later - routing and confinement read the VERIFIED set only, never the typed column - configuring SSO now requires a verified email address - platform admins are emailed when a domain is claimed; nothing is ever sent to the claimed domain, which would let any tenant make this product email third parties Instance-wide providers are exempt from all of it: they are the operator's own configuration and keep the trust they have always had. BLOCKERS FROM THE REVIEW - two unauthenticated remote crashes, both one request, both "async handler throws before its try": `Cookie: st_oidc_tx=%` (unguarded decodeURIComponent) and the fail-closed secret added last commit, which turned a JWT_SECRET rotation into a permanent crash loop. Fixed the CLASS with asyncRoute() rather than the instances. - the SSRF guard was bypassable via IPv4-mapped IPv6 ([::ffff:127.0.0.1]) and also refused every host beginning "fc"/"fd" (fcm.googleapis.com). Addresses are now parsed and compared by RANGE. 42 cases verified. - the takeover fix had NO test — the test named after it asserted two struct fields and passed with the guard deleted. The decision is now a pure function and four mutations were confirmed to turn the suite red. - the PUT path never received the TOCTOU fix, so two orgs could end up holding one domain and forEmail handed routing to the attacker's older row. ALSO - linking compared slugs, so an org could never rotate its own IdP, and fell open on an empty auth_provider. It now asks which ORGANIZATION owns the slug. - an account stranded by a deleted provider can be reclaimed by password reset — proof of the mailbox, which is stronger than the IdP assertion that created it. - /sso/claim accepted a pre-TOTP mfa_pending token and returned the full user row; it now takes a purpose-built 120s claim token with a pinned algorithm and typ. - the rate limiter keyed on a caller-controlled path, so a trailing slash bought a fresh bucket — a real login brute-force bypass. - domain_not_allowed and account_exists_other_provider rendered as "please try again", advice that can never work. - malformed asserted addresses are refused rather than trimmed into shape. - dead config (microsoftTenantId defaulted to 'common', which the provider code now refuses) and the orphaned google-auth-library dependency removed. 1591 tests pass. Domain lifecycle verified end to end against a running server. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 19:23:46 -05:00
ScreenTinker	d26aaebef6	SSO: fix an account takeover, a remote crash, and login CSRF found in review ... Five reviewers went at the two SSO commits. Three of them independently demonstrated a full account takeover, and it was the same defect each time. TAKEOVER. An org admin supplies the issuer and client_id, so they control that identity provider completely and can mint an id_token asserting ANY email with email_verified:true — including a platform_admin's. Every cryptographic check passed honestly, because the attacker IS the issuer. upsertFederatedUser then re-pointed the existing account at whichever provider spoke last, because the only guard was `password_hash IS NULL` — and every SSO-created account has a null password. Sessions were issued as the victim, and the victim's own login then failed forever with subject_mismatch. The rule came from the old Google handler, where it was safe: only the operator could add a provider. Making providers customer-configurable turned it into a takeover primitive and the assumption was not re-examined. Now an org provider may only assert emails inside the domains it registered, and may never adopt an account another provider established. REMOTE CRASH, unauthenticated. The state comparison guarded on UTF-16 character length while Buffer.from produces UTF-8 bytes, so a state of 43 characters containing one multi-byte character reached timingSafeEqual with mismatched buffers and threw — inside an async handler, which Express does not catch, which server.js turns into process.exit. One request per restart killed any instance with SSO enabled. Compared as bytes now, and /api/auth/oidc gained a rate limit. LOGIN CSRF. The callback returned the session token in the URL fragment, so a crafted link installed an ATTACKER'S token and silently signed the victim into their account. The token now goes in a one-shot httpOnly cookie exchanged at POST /sso/claim, which a link cannot forge. FRONTEND, dead on arrival twice over. login.js used `await` in a non-async function — a SyntaxError that takes the WHOLE app down, since app.js imports it statically and there is no bundler. And `esc` was never imported, so the org-SSO button could never render; the ReferenceError was swallowed by the catch written for network failures. Both slipped through because `node --check` parses these files as CommonJS and exits 0 on a broken module. The correct check is `node --input-type=module --check`, and all four frontend files now pass it. PUBLIC EMAIL DOMAINS cannot be claimed. A tenant had claimed gmail.com in review, after which every Gmail user typing their address was offered "sign in with your organization" pointing at that tenant's infrastructure — phishing from this product's own login page. server/lib/public-email-domains.js. MICROSOFT multi-tenant is refused rather than silently broken. `common` metadata advertises the literal template {tenantid}, so the issuer never matches and every login already failed; and loosening that check is nOAuth. A tenant GUID is now required, with a loud warning at boot. SSRF: https only, loopback/RFC1918/link-local refused, redirects not followed, and the test endpoint no longer echoes upstream status for a caller-supplied jwks_uri (it was a readable internal port scanner). Also: an omitted email_verified was accepted (the comment already said it should not be); the domain-uniqueness check raced an 8s network call before its insert and is now inside the transaction; same-org duplicate domains were allowed and made routing depend on table-scan order; routing is now ordered; a client secret that cannot be decrypted fails closed instead of silently downgrading to a public client; SSO audit rows were writing the org id into the deviceId column; and /sso/start was capped at 10/min per IP, which would 429 the 11th employee behind a corporate NAT. Adds per-provider editing in the org admin UI (replace-only secrets — never returned, blank means keep, explicit clear) and a Test button that checks discovery, endpoints and signing keys while stating plainly that it cannot verify the client ID, the secret, or the redirect URI registration. ⚠️ STILL MISSING: domain-ownership verification. A claimed domain means "nobody else had claimed it", not "they own it". DNS TXT proof is the remaining control. 1582 tests pass. New regression tests cover the takeover confinement, ordering, fail-closed secrets, the Microsoft refusal and the public-domain blocklist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 18:12:07 -05:00
ScreenTinker	e97228a502	SSO: per-organization providers, configured by the customer ... Instance-wide providers belong to whoever runs the server. These belong to a CUSTOMER: an organization points ScreenTinker at its own identity provider from Settings → Single sign-on, with no environment variable and no restart. The login flow is unchanged. An org provider is resolved through the same oidc-providers.get(slug) the env ones go through, so there is one authorization request builder, one token exchange and one verifier — not a second, less tested path for tenants. That seam is why Phase 1 put provider lookup behind a single function. ⚠️ An org provider is NEVER published. It is not in /api/auth/providers, because listing a customer's IdP would both offer it to people it does not belong to and leak the customer list from the login page. It surfaces only when someone types an address at one of that organization's domains; otherwise the instance-wide buttons are what you get. The discovery endpoint answers with a BOOLEAN and nothing else — no slug, no display name. Returning "yes, Acme Corp SSO" would turn a guessed domain into confirmation that Acme buys this product, and the slug would hand out a working entry point to their tenant. POST /sso/start repeats the lookup server-side and redirects, so the browser never learns which provider it is being sent to until the provider says so, and the address travels in a body rather than in a URL that lands in history, proxy logs and a Referer. Both endpoints rate limited to 10/min. Other properties, each with a test: - slugs are RANDOM, not chosen, so two customers cannot collide on or guess each other's URL - a domain may be claimed by ONE organization; a second claim is refused, so a tenant cannot capture another company's logins - the issuer is verified by live discovery BEFORE the row is written, so a typo is caught at configuration rather than by a user staring at a failed login - client secrets are optional (PKCE), stored AES-256-GCM via lib/secretbox, never returned; an absent secret on update leaves the stored one alone, which is how a settings form that cannot show it avoids blanking it - cross-org access answers 404, not 403, so an outsider cannot confirm that an organization id exists - signing in through an org provider grants membership of that organization, but never changes an existing member's role Verified live end to end: creation against a real issuer, domain normalisation (`@Acme.CO.UK` → `acme.co.uk`), boolean-only discovery, a rejected domain squat, a rejected bad issuer, and 404 for a foreign organization. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Bvjey4FNam49MN7ybjcq6A	2026-08-10 17:33:32 -05:00
ScreenTinker	1ec32197b2	Let a BrightSign host COLLECT its capture request over HTTP ... Server side of the inverted capture path. The host half is not here — see the end of this message. Every other player is TOLD to capture: the server emits device:screenshot-request over the device socket and the page photographs itself. A BrightSign cannot photograph itself. Video decodes onto a hardware plane the DOM cannot read, so an in-page canvas returns a frame with the content missing — which is why that platform has been answering screenshot requests with a card explaining that the video is uncapturable. Only the host, through the player's own DWS, can get a real frame. The obvious way to ask the host is through the page, and it does not work. On an XT245 (BOS 9.1.93.2) page->host messaging is dead after load: instrumenting the host to echo the `reason` of EVERY roHtmlWidgetEvent produced nothing at all while the page was posting, though the boot-time probe round-trips. The registry is not an alternative either — a running BrightScript does not observe registry writes made by anyone else, proven by writing the key externally through the DWS and watching the host ignore it. What the host CAN do is HTTP; it already fetches its own package updates that way. So the direction is inverted: the request waits here and the host collects it. The image comes back over a plain POST, which means a capture will work even when the page is wedged — exactly when an operator most wants to see the screen. Held in memory on purpose. A capture request is worthless a minute after it was made — someone clicked a button and is watching for the result — so persisting it would only add a way to deliver a stale screenshot after a restart. Bounded and TTL'd so a fleet going offline mid-request cannot grow it, and a repeat request REPLACES rather than queues so a 1fps stream builds no backlog. Authenticated with the same device_id + device_token pair the socket uses. /api/brightsign/package is public because a player fetches it before it has any identity; a screenshot is a picture of a customer's screen and belongs to one display. deviceSocket now exposes ONE ingestScreenshot() used by both the socket handler and the HTTP route, so a BrightSign screenshot reaches the dashboard by exactly the route every other player's does rather than becoming a second, subtly different feature. Note those exports must be attached AFTER `module.exports = function setupDeviceSocket`, which reassigns the object — attaching above it silently wipes them, which cost a debugging round. NOT INCLUDED, deliberately: the host-side poll. Adding it to autorun.brs's main loop kills the BrightScript script within seconds of boot — the page keeps playing, because the widget outlives the script, so from the dashboard it looks healthy. Cause unidentified; BrightScript runtime faults do not reach /api/v1/logs, so there is no error text to read. Half a feature that silently takes down the host is worse than none, so the server waits for a host that can safely ask. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014skWYXJUWhF73EvNPgB2AS	2026-08-07 14:15:06 -05:00
Rob K	bfe8a4c907	Backfill missing thumbnails at boot, and say when ffmpeg is absent ... Ingest-time thumbnail generation is best-effort by contract, so a row that misses it stays bare forever: video uploads on a host without ffmpeg (a SYSTEM dependency nothing surfaced), or content from before thumbnails existed. Operators read that as "thumbnails don't work". Two additions. A [MEDIA] startup diagnostic (async probe, cached) states loudly whether ffmpeg/ffprobe were found, mirroring the [EMAIL] block. And a once-per-boot sweep re-derives metadata for local image/video rows with no thumbnail — serial, paced, delayed past boot, unref'd. The sweep's row UPDATE re-checks that thumbnail_path is still empty so it never clobbers a thumbnail written concurrently by the replace flow, removes its just-written file when the row vanished mid-derive, salvages probed dims/duration even when the thumbnail itself failed, and stops after 25 failures per boot so a library of undecodable clips can't turn every restart into subprocess churn. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0131RYmVh8ePEhparD3mXBhU	2026-08-07 09:30:32 +01:00
ScreenTinker	d7ee971543	Merge 1.9.30: fail loudly on a missing asset; stop an empty playlist wiping the cache ... # Conflicts: # CHANGELOG.md	2026-08-06 17:45:34 -05:00
ScreenTinker	e812f35b6b	Fail loudly on a missing asset, and stop an empty playlist wiping the cache ... Two faults that are live on 1.9.29, both silent, both ending in a dark screen. A missing upload answered 200 OK with Content-Type: text/html and 15KB of the dashboard, under the immutable/30-day header the mount sets before it knows whether the file exists. Every downloader here treats 200 as success, so a panel stores the page AS the video and caches it for a month; Android validates the byte count, not the type, so a correctly-sized page passes integrity and is promoted as a valid asset. Reachable exactly when it hurts — a replace writes a new random filename and unlinks the old one. Now a 404, with the cache header removed. And the service worker treated an empty playlist as "keep nothing". But `assignments: []` is what the server sends for a device between playlists, for a playlist never published, and from the catch when a snapshot fails to parse — so a message that means nothing of the sort deleted every byte of media the panel held. Only survivable while the uplink is up, i.e. exactly when the cache is worthless. Both regression tests drive the whole server or the real worker, because both bugs live in the relationship between two pieces that are individually correct: the order of two mounts, and the difference between "needs nothing" and "did not arrive". Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-06 16:31:53 -05:00
Claude	e4c25c39df	Describe a portrait video wall as portrait, and stop a wall hiding its screens ... #236: the wall canvas was secretly framebuffer space rather than the wall as the audience sees it. Invisible while every panel is the normal way up, and actively misleading the moment one isn't — two portrait-mounted panels standing side by side had to be STACKED VERTICALLY in the editor, with a pre-rotated copy of every video, before the output came out right. It worked, but only after trial and error, and it meant a portrait wall could never reuse content as-is. Each panel now carries a mounting rotation (0/90/180/270 clockwise, the same convention as the per-device orientation setting), the canvas means the physical wall, and the player works out the mapping. The geometry lives in one place, server/lib/wall-geometry.js, because four players have to agree on it to the pixel across a seam. Existing walls need no migration and do not move. Every wall in the field is rotation 0, and that case takes the original expression verbatim on all three players rather than the algebraically-equal centre-based one — the two differ in the last float bit, and a float's worth of disagreement between two panels is a hairline seam down a wall that was aligned yesterday. Pinned by the first test in wall-geometry.test.js and by wall-payload.test.js. While a display is in a wall its panel rotation replaces its own orientation: both describe the same physical fact, so honouring both turned the content twice. #235: a wall replaced its members' cards, so one dead panel of a four-panel wall was invisible from the dashboard, and inspecting a single screen meant pulling it out of the live wall and putting it back. The wall screen now lists its panels with live online state, a per-panel screenshot request, and a link to each device's page; the dashboard wall card carries per-member status chips that track socket updates. Tests: wall-geometry.test.js re-simulates the CSS box independently and asserts each panel's viewport maps onto exactly its own rect of wall space, for every rotation, plus a mixed wall and the Tizen player's hand-ported copy executed against the canonical rule. Full server suite green (1260). Not verified here: the Android and Tizen renders on real hardware. Kotlin compiles clean; the maths is shared/tested, the view plumbing is not.	2026-08-06 09:46:31 -05:00
ScreenTinker	c2240288a7	Serve the service worker from the root, so its scope needs no header to survive ... Found deploying 1.9.29 to production. A worker's scope defaults to its own directory, so /player/sw.js could only control /player/ and below; the fix was to request a wider scope and permit it with Service-Worker-Allowed. That works right up until something between the origin and the browser does not pass the header on. Cloudflare served a CACHED response for that path across the deploy — headers and all — and the registration failed outright. A rejected registration is worse than a narrow one: the player runs with no worker at all, on every URL, and nothing about it is visible from the server. The origin was sending the header correctly the whole time; a cache-busted request proved it. It self-heals when the edge entry expires, which is precisely the kind of fix nobody should have to know about. Served from /, the default scope is already the whole origin and no header has to survive the trip — through Cloudflare, through whatever a self-hoster puts in front of it, or through a corporate proxy we will never see. /player/sw.js keeps serving for players still asking for it, and the header is still sent where it does survive. Verified in a real browser: all three of /player, /player/ and /player/index.html are controlled from root scope. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-06 09:05:06 -05:00
ScreenTinker	75c1940821	Fix the worker scope that made web offline playback silently inert, and prune superseded assets ... Found by QA against a real browser, not by any test in the suite: the bug lived entirely in the relationship between a URL and a header. A service worker's default scope is its own directory, so /player/sw.js could only ever control /player/ and below — which does not include /player itself. The player is served at all three of /player, /player/ and /player/index.html, and /player is the one that gets used: it is what the dashboard shows and what gets typed into a panel. On that URL registration SUCCEEDED, logged "Service Worker registered", and then controlled nothing. No shell cache, no content cache, no offline playback, no error. Every web and BrightSign panel served at /player has been running with its offline story switched off. Registration now asks for scope '/' and the server sends Service-Worker-Allowed to permit it. Both halves are required — without the header the registration does not narrow, it fails outright. Also: revision-keyed sweeping could not reclaim a replaced asset's predecessor. A replace writes a NEW randomly-named file, so the superseded copy lives at a different path entirely and nothing keyed on the asset path can find it; it would sit there until the quota evicted it. The player now declares the complete set of media it needs — the raw assignments, so multi-zone items are included and a prune cannot delete something a zone is still playing — and the worker drops everything else. QA results this pass: web player 18/18 against a real browser (cold start with no network renders a cached video at readyState 4); Android 12/12 on a device including a replace round-trip that re-fetched 6MB and then dropped it for the new bytes, and a cold start with the server stopped that played from disk; Tizen 11/11 for the no-storage path, which must degrade to streaming and must not claim a capability it cannot honour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 16:30:12 -05:00
ScreenTinker	604c390a55	Portrait on the web player was 420px off-screen — rotating a box does not move it ... Reported as "rotation doesn't work correctly". It is a geometry bug, not a rendering one, which is why it reads as mysterious. #playerContainer is pinned `inset: 0`. Rotation set width:100vh, height:100vw and rotate(90deg) — leaving the box in the TOP-LEFT corner and spinning it about its own centre rather than the viewport's. On a 1920x1080 panel the content landed at x -420..1500, y 420..1500 against a viewport of 0..1920, 0..1080: correctly rotated, wrongly placed, cropped on two edges. Tizen already did this correctly — top/left 50% plus translate(-50%,-50%) — and Android does the equivalent with translationX/Y of (w-h)/2. The web player was the odd one out, and BrightSign inherited it on top of its own hardware-plane problem. The rule now lives in server/lib/orientation-style.js, served to the player from its single source, with the arithmetic pinned by tests that compute where the rotated box actually lands on 16:9 and 5:4 panels. Three things those tests hold that are easy to get wrong: the translate must come BEFORE the rotate (transforms apply right-to-left, so reversing them rotates the correction too), 180 must NOT swap dimensions (the box already fits; swapping letterboxes it), and landscape must clear EVERY property the rotated state set (a half-reset leaves the container stuck at 100vh wide, so rotation appears to persist after switching back). 1074 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 12:58:50 -05:00
ScreenTinker	cf1124d687	Mute reaches YouTube items — it never did, and failed opposite ways per player ... Muting was implemented three times and agreed nowhere. A YouTube item is a cross-origin iframe, so `el.muted` reaches nothing; only the IFrame API can touch it. Both browser-family players got this wrong, in opposite directions: web playerVars.mute was `userHasInteracted ? 0 : 1` — autoplay policy and NOTHING else. An item an operator muted in the admin console played WITH SOUND, a wall follower blared alongside its leader, and the real-time device:mute-changed toggle only ever touched `<video>`. onReady then unmuted unconditionally, and the click-to-unmute overlay appeared on deliberately-muted items and undid the operator's setting. tizen the embed URL hardcoded `mute=1`, so YouTube there was PERMANENTLY silent: the per-item flag was never read and nothing could unmute it. device:mute-changed did nothing at all, because it dereferenced a <video> that is null for a YouTube item. Android was already correct and is unchanged — it is the reference here. The rule now lives once, in server/lib/media-mute.js, served to the web player from its single source the same way schedule-eval.js is, and mirrored in Tizen (which ships inside the .wgt and cannot import it). The ORDER is the substance: a wall follower is always silent (one wall, one audio source) > autoplay policy, which is a hard constraint rather than a preference because unmuted playback without a gesture is refused outright and costs the VIDEO > a live operator toggle, who is looking at the screen > the item's stored flag. shouldOfferUnmute() exists so the prompt only appears when a gesture is the ONLY thing in the way. Prompting on a muted item trains viewers to click a button that undoes an operator's decision. Tizen gains enablejsapi + a postMessage bridge so a live toggle flips the embed without reloading it — reloading would restart the video from zero every time someone touched the control. 11 new tests pinning each precedence step separately; 1055 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-05 10:50:59 -05:00
ScreenTinker	8fd6eb75d5	BrightSign: cache content for offline, and let the package update itself ... Two gaps that both end the same way — a panel nobody can fix without a van. OFFLINE. Content bytes were never persistently cached. The service worker skipped /uploads/content/ and leaned on the browser's HTTP cache, which is reasonable on a desktop and is not a documented-persistent store here: BrightSign guarantees survival across reboots for IndexedDB, localStorage and SQLite, and their own answer for offline video is to cache the bytes explicitly. A panel could come back from a power cut with its playlist intact — that lives in localStorage — and no media to play it with. The reason content was skipped is real, and player-cache-policy.js is what makes intercepting it safe. Seeking video issues range requests, and naive caching is worse than none: storing a 206 as the whole file means every later full request gets a fragment, and answering a range request with a 200 makes some media stacks fail outright. So only complete 200s are stored, and ranges are served by slicing the stored body into a correct 206. The content cache survives shell re-versioning, or every deploy would re-download the playlist over a link that may be exactly what is broken. SELF-UPDATE. The package can replace autorun.brs, so a truncated file is a dark panel with no app underneath. The safety is the ordering: download to .part, verify sha256 AND size, then delete the .done marker, rename, reboot. Marker first is not stylistic — leaving it makes the next boot skip the archive and the update silently never happens. A failed extract parks the zip as .bad instead of retrying every boot, which would be a loop indistinguishable from a hardware fault. sha256 because that is what roMessageDigest can compute; a checksum the player cannot verify is an unverifiable package. The decision lives on the server and is unit-tested, and the host only executes it — re-implementing the version comparison in BrightScript would put the prerelease trap somewhere untestable. That trap is honoured directly: a player on 1.9.29-rc1 is running something semver-OLDER than 1.9.29, so an opted-in player HOLDS a prerelease of its own core rather than being pulled off the build it was given to test. Narrowly — a newer core still lands, so opting in never means never updating again. Both loop conditions are closed by construction. The manifest and the download come from one buffer hashed once, so a checksum cannot describe bytes we are not serving. And the version is stamped into autorun.brs at build time by both builders, so the script reports the version it actually is — otherwise the player applies the update, still reports the old version, and is offered the same package forever. Failure always degrades to "keep running the old version": an unreachable manifest, a missing checksum, a failed verification, a full attempt counter and an unbuildable package all resolve to skip. 998 tests pass (was 954).	2026-08-05 10:09:00 -05:00
ScreenTinker	5901067d8a	Finish the BrightSign port: native sync, offline fallback, multicast guard ... st-sync.js wraps SyncManager, the native protocol. Three properties drove the shape of it. It repeats the sync broadcast at 1Hz so a player powered on late still joins, which means acting on every repeat would reload the video once a second forever — on screen that reads as a stutter, not as a sync fault, so the id dedupe is mandatory rather than an optimisation. The leader starts from its OWN broadcast rather than at announce() time, or it runs ahead of the group by the width of the network. And attachVideo refuses an element with no setSyncParams instead of half-syncing it. offline.html is the local fallback the host falls back to after three failed loads. It names the server, keeps probing with capped backoff so a site full of panels cannot storm a server that is coming back, and asks the HOST to restart the player when it answers — never navigating itself, for the same reason the player never reloads itself here. The resolver now models multicast reach. All-BrightSign groups spread across subnets no longer get native sync: each subnet would sync neatly within itself while drifting from the others, and the dashboard would show a healthy group throughout. The IP comparison is a heuristic so it is used in one direction only — differing networks are evidence against, matching ones are never proof for, and unknown addresses block nothing. st-sync.js is served from its single source like the bridge, and the SD card deliberately carries neither: the player pulls both from the server so a stale copy on a card can never skew from the player using it. 948 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-04 21:43:42 -05:00
ScreenTinker	ce854ff2d8	Wire the BrightSign bridge into the web player ... The bridge and the host existed but nothing loaded them. Now the player does. restartPlayer() replaces every location.reload() call site. On BrightSign a page-initiated reload does not reliably bring the roHtmlWidget back, so the page asks the host to rebuild it and only falls back to reload() when no host is there to take the request. That covers the deploy path, the operator refresh, the service-worker activation and the manual reset. Identity now round-trips through the registry, which outlives localStorage on this platform: getConfig() adopts a registry identity when local storage comes back empty, instead of re-pairing and spawning a second row for a panel that is already provisioned. The operator reset clears the registry too — otherwise it would clear localStorage, get the same identity straight back on the next boot, and reset nothing. Registration reports platform 'brightsign' rather than "Chrome 120", which is what sync-backend.js resolves native-vs-ours from, plus model, OS, serial and which output this widget paints. Dual output needed a collision fix: autorun.brs gives the second HDMI output its own widget, and both widgets share an origin, a registry and one SD storage_path. Un-namespaced, output 2 would read output 1's config, install salt and device id and the two would collapse into a single device row. Storage keys and registry keys are now suffixed per output; screen 1 keeps the bare names so nothing existing moves. The bridge is served from its single source so the copy the player loads can never skew from the one on the SD card next to autorun.brs, and it is served to every player rather than gated on a user agent — a panel reporting an unexpected UA would otherwise silently lose restart-instead-of-reload. Two test harnesses extract player functions and run them in an isolated scope, so they now supply SCREEN_SUFFIX; one gained a case proving two outputs of one player get distinct identities. 927 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-08-04 21:07:47 -05:00
Claude	b44f9d4f03	Serve a beta APK alongside the stable one, and let a display move between them ... 1.9.26's opt-in was passive: it stopped a sideloaded build being reverted, but there was still one APK slot and latest_version was the server's own VERSION, so a beta had to be installed by hand on every display. This makes it a real channel. - apk-cache tracks two slots. ScreenTinker-beta.apk is optional and reaches only displays with ota_beta = 1. - A beta must DECLARE its version in a sidecar ScreenTinker-beta.apk.version. The server cannot infer it — stable's version is the server's own constant because the two ship together, and reading it from the APK means parsing binary AndroidManifest.xml on the request path. If the sidecar is missing or unparseable the channel does not activate at all and opted-in displays keep getting stable. Failing closed matters: advertising a version that does not match the bytes served is the OTA-loop condition this fleet has been bitten by before. - The check and the download resolve the channel identically and fall back to stable identically, so apk_size always describes the bytes actually delivered. No APK change was needed — the client already fetches whatever download_url it is handed, so displays in the field can be moved between channels from the dashboard today. Switching back needed care. Stable is semver-OLDER than the beta it replaces, so the ordinary "never offer a downgrade" rule stranded the display and unticking the box would have been another silent no-op. The first attempt returned any non-opted-in display running a pre-release — which broke a #144 test, correctly: that would have dragged every existing pre-release tester back to stable the moment their server upgraded, the exact harm the opt-in exists to prevent. So the return now requires evidence we actually served that display the beta channel (devices.ota_channel_served, written once on change, not per check). A tester ahead of the server on their own build is left alone exactly as before. Documented in the README, including the constraint that makes the switch-back physically possible: beta builds must carry a versionCode no higher than the stable they branch from, because Android refuses to install a lower one. Equal numbers install in both directions. Verified end to end against a live server with two real signed APKs: stable serves 1.9.26, beta serves 1.9.27-rc1, an unknown channel falls back to stable, removing the version file deactivates the channel, and the full opt-in -> serve -> switch-back lifecycle produces offer / up-to-date / channel-return in order. 859 server tests green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-07-30 19:12:46 -05:00
Claude	301c76c3f7	Let a display opt in to pre-release builds, so a test build is not reverted under the tester ... Handing someone a test build was a trap. A prerelease sorts BELOW its own release — 1.9.25-fix234d is semver-older than 1.9.25 — so a sideloaded display asked "anything newer?", was correctly told yes, and updated itself straight back off the build we had asked someone to test. Same versionCode, so Android installed it without complaint. Silent, and within minutes. That is what happened on #234: the reporter installed the fix, tested for an evening, and reported nothing had changed. They were right. Their tablet was running the old code again by then, and I had told them it was fixed without ever checking what the device reported. Adds a per-display opt-in (devices.ota_beta, default 0, checkbox next to the OTA toggle). When set, the display keeps a prerelease of the CURRENT core instead of being pulled back to its release. Deliberately narrow in one direction and deliberately wide in the other: - Narrow: it only holds a prerelease of the core already installed. A plain release, a -patchN build, an upgrade to a newer core, and a display ahead of the server all behave exactly as before, and the flag defaults off so a fleet that never sets it is unaffected. - Wide: an opted-in display is exempted from the superseded-prerelease guard. That guard would otherwise pin a tester on an old test build permanently — an older-core prerelease is never offered anything, so they would have to notice and sideload their way out. Writing the test is what surfaced that; opting in must never mean never updating again. 9 tests covering both directions, including that shipping a newer release pulls a beta display back onto the release line. 845 server tests green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-07-30 18:35:31 -05:00
ScreenTinker	c779d62d63	Add an operator override for self-update on MDM-managed panels ... A player stands down from self-updating when another device owner manages the panel, on the assumption that the MDM distributes packages instead. That assumption does not always hold: an operator may run an MDM for policy alone and still want ScreenTinker's OTA to own the player. Until now there was no way to say so — the stand-down was a client-side decision with no operator input. OTA_ALLOW_MANAGED_DEVICES=1 makes the server advertise `allow_managed: true` in /api/update/check, and players skip the stand-down. Default off: the safe behaviour stays the default, and only an explicit opt-in changes it. Absence is not consent. The client parses the field with a false default, so a newer player against an older server that has never heard of it still stands down; and the server always emits the key, so a player can tell "the operator said no" from "this server has no opinion". Config parsing is strict for the same reason — only 1/true enable it, and anything else, including a plausible typo like "ture" or "yes", lands on the safe side rather than riding JavaScript truthiness. This deliberately does NOT grant silent install. Off device-owner, and without DELEGATION_PACKAGE_INSTALLATION delegated by the MDM, Android still raises a confirm dialog somebody has to accept, so the override alone will not fix a fleet whose installs are failing at that dialog — delegating the scope is the real fix there. The README says so at the point of use, because reaching for this flag is the natural mistake. Only reachable because the stand-down now runs after the version check rather than before it; it needs the server's answer in hand to consult.	2026-07-28 23:07:30 -05:00
ScreenTinker	792013e36c	Record auth rate-limit rejections so they can be measured ... The auth limiters are app.use middleware that return 429 before the handler that writes activity_log, so a rejection left no trace anywhere — the limit suppressed the record of itself. Four production IPs sit at exactly ten logins a minute and there was no way to tell whether that is one attacker or an office whose staff share an egress address, which is the difference between the limiter working and the limiter locking out customers. The rejection count does not answer that. The number of distinct accounts per IP does: one account hammered is the limiter doing its job, several accounts each denied a few times is a shared egress. Both are now recorded, and a platform-admin-only endpoint reads the tally back. Identifiers are salted-hashed with a per-process salt and only ever counted, so this cannot accumulate into a roster of a customer's addresses. Memory is bounded per key and overall, and says when a count was capped rather than silently undercounting. Behaviour is unchanged: same status, same body, and the recording is wrapped so telemetry can never break the limiter. A test asserts ten through then 429 with the identical response shape, since a diagnostic that alters what it measures is worse than none. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL	2026-07-28 14:01:00 -05:00
ScreenTinker	d4cf1d4123	Merge branch 'feat/self-service-password-reset'	2026-07-27 11:21:36 -05:00
ScreenTinker	b7d55595af	feat(auth): self-service password reset ... Until now the only ways back into an account were an admin setting your password for you or shell access to run scripts/reset-admin.js. A self-hosted operator who forgot their password had no path at all, and the admin-reset route explicitly refuses to reset a platform admin's password — so a single-admin instance was unrecoverable without a shell. The per-account login lockout added recently makes that sharper: a user who forgets their password will hit the lockout and see the same generic error, with no way out. Two unauthenticated endpoints (they must be — the user cannot log in): POST /api/auth/forgot-password { email } -> always the same 200 POST /api/auth/reset-password { token, password } -> 200 / 400 The properties that matter, each covered by a test: - NO ENUMERATION. The request endpoint answers identically — same status, same body — for a real address, an unknown one, an SSO identity with no local password, and a malformed string. The frontend shows the same confirmation even on a network error, so the client cannot leak what the server refused to. - NO MFA BYPASS. Completing a reset does NOT issue a session; the user signs in afterwards, so a TOTP-enabled account still clears its second factor. Returning a token here would turn "read one email" into a full session without the second factor. - SINGLE USE, SHORT LIVED. 32 random bytes, stored only as a SHA-256 hash (same discipline as email verification, recovery codes and API tokens), 1h TTL, and the redeeming UPDATE is conditioned on the hash still being present so concurrent redemptions cannot both win. - LOCAL ACCOUNTS ONLY. SSO identities have no local password; no token is minted. - IT ACTUALLY UNBLOCKS YOU. A completed reset clears the per-account login lockout and must_change_password, otherwise someone who locked themselves out would reset and still be locked out. Rate limited: 5/min on the request (it sends mail to a caller-supplied address), 10/min on the redeem. If no email transport is configured the response is unchanged — no oracle — but the server logs loudly, because the user will otherwise wait for mail that cannot arrive and the generic response cannot tell them. Frontend: a "Forgot your password?" link on the sign-in card, a request card, and a new-password card. app.js had to learn #/reset-password explicitly — the auth guard rewrites any unauthenticated hash to #/login, which would have discarded the one-time token in the emailed link and made it silently do nothing. Migration adds users.password_reset_hash / password_reset_expires: additive, nullable, idempotent; a code-only rollback leaves two dead columns. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 11:19:39 -05:00
ScreenTinker	090b6c12cb	fix(pairing): expire a pairing code on device liveness, not row age ... A screen that was still connected and still displaying its pairing code could not be paired. Reloading the player produced the same code, and the on-screen instruction ("restart the display to get a new code") could not help. devices.created_at is written once, at first registration, and the row is never recreated: a player persists its device_id and its pairing code in local storage and re-registers with them forever. Expiry was measured from created_at, so 15 minutes after first boot the row became permanently unclaimable while the device kept heartbeating — and a restart reused the stored identity and reproduced the same code, so there was no way out. Observed in production: an unclaimed web player, still online and heartbeating, whose row was created 4 days 20 hours earlier and had been unpairable for all but its first 15 minutes. Prod is carrying several such rows; alpha has some 13 days old. Key expiry on last_heartbeat instead, falling back to created_at for a row that has never checked in. That answers the question the operator actually has — is this screen still there showing me this code? — while keeping the property the expiry exists for: a device that has genuinely gone away still expires. Trade-off, taken deliberately: a code stays claimable while its screen is connected rather than for a fixed 15 minutes. That is what the product implies, since the code is on the screen the whole time, and guessing is bounded by lib/pair-lockout (5 failures per IP per 15 min) and the 5/min route limit rather than by this TTL. SERVER-ONLY. The player's device:registered handler reads only device_id and device_token and has no way to display a server-issued code, so reissuing one would have left fielded players showing a stale code — strictly worse. This fix needs no player update and un-strands every already-affected device in the field on deploy. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 10:59:38 -05:00
ScreenTinker	d23a5205d4	Merge branch 'fix/pin-generation-csprng' into release/auth-campaign ... # Conflicts: # server/server.js	2026-07-26 16:22:59 -05:00
ScreenTinker	0e9a842eb3	Merge branch 'fix/screenshot-workspace-authz' into release/auth-campaign	2026-07-26 16:21:59 -05:00
ScreenTinker	dce0bc6f54	fix(devices): generate access-gating six-digit codes with a CSPRNG ... The on-device settings PIN (devices.settings_pin, minted at pairing) and the pairing code assigned to imported devices both came from `Math.floor(100000 + Math.random() * 900000)`. Math.random is not a CSPRNG. V8 implements it as xorshift128+, whose internal state is recoverable from a handful of consecutive outputs, and every call in a process draws from that one shared stream. Both values are also observable by ordinary users — settings_pin is returned in device API responses today — so a user who collects a few outputs could predict the values minted around them, including for other tenants. lib/numeric-code.sixDigitCode() uses crypto.randomInt, which is CSPRNG-backed and rejection-samples so the distribution stays uniform. Range is 100000..999999 inclusive, identical to the old expression, so codes are still exactly six digits with no leading zero — the on-device keypad and pairing UI are unchanged. Deliberately NOT converted, because neither gates access: the image-generation seed in lib/image-gen.js, and the anti-burn-in pixel jitter inside generated widget HTML. Also unchanged: the settings_pin backfill in db/database.js, which uses SQLite's random() — that is ChaCha20 seeded from OS entropy, not a weak PRNG. This is the generator half of the finding only. The separate half — that settings_pin is returned to every workspace member, including read-only roles — is a response-shape change and waits on the consumer enumeration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 14:24:03 -05:00
ScreenTinker	dda6f5b41e	fix(devices): authorize the screenshot route on the device's workspace ... GET /api/devices/:id/screenshot returns a live picture of what a screen is showing, but it was still authorized pre-tenancy: `device.user_id !== user.id`, with a role bypass listing 'admin'/'superadmin'. Three consequences, all now covered by tests: - `device.user_id &&` SHORT-CIRCUITED. A device with no user_id — never paired, or its owner deleted — skipped the ownership test entirely, so any authenticated account on the instance could read it. An unpaired panel displays its pairing code on screen, so that image is also a route to claiming the device (AUTH-10, out of scope here but connected). - 'platform_admin' was absent from the bypass list. #14 renamed 'superadmin' to 'platform_admin', so an actual platform admin fell through to the ownership test and was denied unless they happened to own the row. - Workspace members other than the owner were denied a device they administer through every other endpoint. Now uses accessContext() against the device's workspace — the same helper routes/devices.js uses — which covers direct membership, org-level access and platform staff in one call. A device with no workspace is denied outright rather than defaulting open. Deliberately unchanged: the ?token= query-parameter mechanism on this route, which is a separate finding with its own blast radius. No response shape change: still 200 / 401 / 403 / 404 with the same bodies. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 14:17:54 -05:00
ScreenTinker	6b082cfad0	fix(uploads): derive stored type from file content, and never serve uploads as documents ... Uploaded files are served from the SAME ORIGIN as the dashboard, so how a browser interprets them is a security boundary. Two things decided that interpretation, and both were caller-controlled: the stored extension came from `path.extname(originalname)`, and the only type check read `file.mimetype` — a request header. A caller could therefore choose to have their bytes served as an active document from the app origin. Two independent invariants now hold the boundary: 1. INGEST — lib/upload-sniff.js sniffs magic bytes after multer writes a neutral `.part` file (diskStorage names the file before any bytes exist, so the sniff cannot happen there), maps the result through a hardcoded mime->extension allowlist, renames accordingly, and stores the sniffed mime. Unsupported bytes are refused with a 400. 2. SERVING — upload responses carry `Content-Security-Policy: sandbox`, so if a response is ever treated as a document it lands in an opaque origin with scripts disabled. Anything outside the inline-safe extension set is additionally forced to download. This holds regardless of how a file reached disk, so a future gap in (1) is contained rather than exploitable. Applied at every instance of the pattern, not just the first: lib/content-ingest.js, the /replace route, the four content-serving paths across server.js and routes/content.js (the latter pair currently shadowed by mount order, which is not a guarantee), and the ZIP-import path in routes/status.js, which took its extension from the archive entry. SVG stays accepted and stays inline: white-label logos are SVG, and octet-stream + nosniff makes <img> fail. Scripts in an SVG never run in an image context, and the sandbox CSP covers the one case where they would — a direct navigation. SVG is also no longer handed to sharp, which removes the librsvg path where the open libvips CVEs live. Existing rows are untouched — no migration. The four upload fixtures in agency.test.js uploaded `Buffer.from('x')` declared as image/png; that is the exact "declared type is a lie" case this closes, so the fixtures now use real PNG bytes. No assertion changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 11:47:09 -05:00
ScreenTinker	c4b5a8679e	refactor(auth): centralise session token resolution across manual verify sites ... Six places verified a session JWT inline instead of going through requireAuth, each repeating a slightly different subset of its checks. Introduce resolveSessionUser() in middleware/auth.js as the single definition of "this token is a usable session, and here is whose it is", and route all of them through it: the three /api/status token routes, the screenshot route, the content-reference gate, and the /dashboard socket handshake. requireAuth is now a thin wrapper over the same helper, so the two cannot drift. Also: - Give the pre-TOTP token a distinct audience so it is redeemable only through verifyMfaPendingToken (POST /api/auth/totp/verify). verifyToken refuses any token carrying an audience, so a token minted for one purpose cannot be redeemed on another path. - The dashboard socket handshake now takes userId/userRole from the live users row rather than from the token claim, so role changes take effect on the next connection instead of riding the token's remaining lifetime. - Add test/session-token-resolution.test.js covering all six surfaces, including the socket handshake. Every call site keeps the status code and error body it returned before. Net query cost: the content-reference gate and the socket handshake each gain one users-by-id lookup (the same one requireAuth already does per request); the other four are unchanged or replace an equivalent lookup. In-flight pre-TOTP tokens are invalidated by the audience change; they live 5 minutes, so the window is a re-login at worst. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-24 20:58:05 -05:00
Fabian Mendoza	e7483dfc24	feat(ui): show server URL in Add Display modal + GitHub Releases link on /download/apk (#210) ... - Add Device modal now shows the server URL and full Smart TV player URL - Smart TV note changed from bare /player to full URL (dynamic via JS) - /download/apk error page now includes a download link to GitHub Releases - i18n keys added in en + es, old smart_tv_note removed	2026-07-23 10:25:00 -05:00
ScreenTinker	b938fce368	feat(auth,tizen): TOTP 2FA UI, email verification on signup, Tizen SSSP install ... Three features from this session, full server suite green (535/535). TOTP 2FA (#100) — backend shipped without a UI; add it: - Login: mfa_required -> 6-digit challenge (recovery codes accepted) -> /totp/verify. - Settings > Account: enable (QR + confirm -> recovery codes once), regenerate, disable; SSO accounts see "managed by your identity provider". - /totp/setup returns a server-rendered qr_data_url (bundled qrcode dep). keyuri folds the request Host into the issuer so multi-instance accounts are distinguishable in the authenticator app. Email verification on signup — hosted HARD-block / self-host SOFT-nudge: - email_verified column; existing users asked on first login (SSO + platform admins grandfathered); single-use 24h tokens (SHA-256 hashed). - Gate engages only when email is configured (never locks out a no-mail instance). GET /verify-email + POST /resend-verification (generic, no account enumeration). - Client: "confirm your email" flow + resend, verified/error toasts, self-host banner; onAuthSuccess refuses a tokenless response (defensive). Tizen SSSP URL-Launcher install — Fusion-style one-URL native install: - Server hosts /tizen/sssp_config.xml (dynamic <size>, always matches the served .wgt) + /tizen/ScreenTinker.wgt + a human landing. lib/wgt-cache.js resolves the signed .wgt (/data mount wins, mirroring the APK). - build-wgt.sh also emits a static sssp_config.xml for CDN hosting. - Retail panels require a Samsung Partner cert; dev-mode is SDB self-signed only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-22 21:08:50 -05:00
screentinker	96b71a0d56	feat: transition engine — GL wipes across web, Tizen & Android (+ image↔video) (#204) ... Client-side GL Transitions v1 across all three players with never-blank degradation: shader lib + generated manifest + real-WebGL CI, transition-as-widget normalization, persistent WebGL/GLES2 compositors (web/Tizen/native Android), image↔video wipes, SSRF-hardened media proxy, decode-gated image preload, dashboard picker. Fixes the playlist change-fingerprint that dropped transition edits. Alpha + on-device soak validated.	2026-07-20 16:45:32 -05:00
screentinker	335681b907	feat(directory-board): panel-ring scroll + in-place refresh + per-device frame diagnostic (#203) ... Compositor panel-ring board scroll (smooth on Blink+Gecko, no blank-on-refresh), a per-device frame-rate diagnostic widget + dashboard card, and web/Android/Tizen device-id passthrough to widget render URLs.	2026-07-17 20:17:21 -05:00
screentinker	5f5ec88eb0	fix(widgets): put the CORP: cross-origin header on the route that actually serves content (#196) ... Follow-up to #195. The CORP fix there landed on routes/content.js `/:id/file`, but that handler is SHADOWED: server.js registers a public `app.get('/api/content/:id/file')` (and `/thumbnail`) BEFORE the auth-gated content router, and that public route (gated by playlist/widget reference) is what actually serves widget logo/background images. So the header never changed on the wire — origin still returned CORP: same-origin and the player's sandboxed (opaque-origin) widget iframe kept getting NS_ERROR_DOM_CORP_FAILED / 0 bytes. Set Access-Control-Allow-Origin: * + Cross-Origin-Resource-Policy: cross-origin on the real public routes in server.js: /file, /thumbnail (local), and the remote-thumbnail proxy. Revert the now-dead content.js edit so the fix lives only where the bytes are served. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-16 14:02:31 -05:00
screentinker	a15086540f	feat(widgets): directory-search widget (interactive search of a directory board, live-sync) (#188) ... * feat(widgets): add directory-search widget An interactive, walk-up search view of an existing directory-board. It references a source board by id (no data copy), so a venue can run the scrolling board on a main screen and a search view on a tablet, letting people find an entry instantly. Server (routes/widgets.js): - register 'directory-search' + renderDirectorySearch(): resolves the source board, inlines its categories as one \u003c-guarded JSON blob, renders all text via textContent (XSS-safe), live case-insensitive filter over identifier/name/subtitle (debounced), grouped results, available styling, optional touch on-screen QWERTY keyboard that drives the same filter path. - missing / non-directory-board source -> friendly full-page fallback, not a 500. - live-sync while open is out of scope; left a // TODO for a poll hook. Frontend editor (views/widgets.js): type + magnifier icon, source-board dropdown (from loaded widgets, filtered to directory-board), title, logo (reuses the board's picker), placeholder text, theme, on-screen-keyboard toggle; getConfigFromForm case. i18n: widget.dirsearch.* + type keys in en/es/it/de/pt/fr. docs: openapi widget_type enum. Tests: server/test/directory-search.test.js. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(widgets): live-sync for directory-search (poll source board, no reload) Reflect directory-board edits on an open directory-search page without a reload. - New public GET /api/widgets/:id/data.json returns { categories } for a directory-board (404 for missing/wrong-type so the page keeps last-good data on a transient miss). CORS-open (ACAO:*) + no-store so a null-origin sandboxed widget iframe can read it; exposes only data already public via /render. Exempted from CSP + auth in server.js alongside /render. - directory-search page inlines its source_widget_id and polls the board's data.json every 30s via a relative URL (works behind a proxy/base path and from a null-origin iframe). Only rebuilds + rerenders when the data actually changed, so a mid-search view isn't disturbed; skips while document.hidden; keeps last-good data on any fetch error. Flatten logic factored into buildFlat() and reused by the poll. Tests: data.json feed (categories, CORS header, 404s) + poll wiring in directory-search.test.js (13/13). Verified live in a browser (page.clock fast-forward): editing the board updates the search page with no reload. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(android): let player WebViews take touch focus for interactive widgets directory-search is served through the existing generic widget path (loadUrl <server>/api/widgets/:id/render), so it already renders on Android with JS + DOM storage + mixed-content enabled, same-origin (so its live-sync fetch of the source board's data.json works), and no touch blocking. Add isFocusable/isFocusableInTouchMode to the shared WebView config so the search field reliably takes a tap/cursor inside the kiosk lock-task WebView. Harmless for passive widgets (board/YouTube have no focusable inputs); the widget's own on-screen keyboard still drives the filter when the system IME is suppressed. Verified with :app:compileDebugKotlin. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 08:00:22 -05:00
screentinker	cf4c71d7d0	feat(email): SMTP transport as an alternative to Microsoft Graph [#173] (#179) ... Adds a pluggable email transport so self-hosters without Azure/M365 can send mail through any standard SMTP server (Postfix, Gmail, Mailgun, SendGrid, corp relay). Graph stays the default; behavior is byte-for-byte unchanged when EMAIL_TRANSPORT is unset or "graph". - config: EMAIL_TRANSPORT ("graph"|"smtp", default graph) + SMTP_HOST/PORT/ SECURE/USER/PASSWORD/FROM. - services/email.js: branch by transport behind the SAME public sendEmail()/ isConfigured() surface. SMTP via nodemailer (lazy-required, like MSAL). Shared across both transports: the "[ScreenTinker] " subject prefix (unless rawSubject), the GRAPH_DEV_RESTRICT_TO allow-list, html-from-text derivation, and the never-throws contract (failures log + return sent:false). SMTP_SECURE true=implicit TLS(465)/false=STARTTLS(587). Auth optional (unauthenticated relay ok); SMTP_USER without SMTP_PASSWORD is flagged. SMTP_FROM parses "Name <addr>". New emailConfigStatus() for startup diagnostics. - server.js: startup logs the transport and a LOUD error when the selected transport is partially configured (some fields set, others missing) or when EMAIL_TRANSPORT is invalid (falls back to graph). A fully-unset transport stays a silent stdout fallback (unchanged dev behavior). - nodemailer ^6.9.16 added as a production dep (bundled in the Docker image). - .env.example + README: SMTP config section, Gmail example, transport table. - test/email-transport.test.js: 15 tests — transport selection, config validation (missing/partial/invalid), SMTP message building (from/prefix/ fromName override/text alt), sendEmail routing (mocked nodemailer), rawSubject, dev-restrict on smtp, and the smtp_error never-throws path. 462/462 server tests pass. Boot verified for all four states (configured, misconfigured, invalid, default). Closes #173 Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 15:56:22 -05:00
ScreenTinker	406872c439	fix(server): serve /integrations/ hub explicitly so the nav link isn't the login page ... express.static runs with index:false, so a bare /integrations/ fell through to the SPA catch-all and rendered the dashboard login instead of the integrations hub — the top-nav "Integrations" link, the canonical, and the sitemap entry all dead-ended at login. Add an explicit route (like /agency, /sitemap.xml): /integrations/ -> the hub's index.html, and /integrations -> 301 /integrations/. Spoke pages are real .html files already served by static. Folded into a re-cut of v1.9.6. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 12:27:38 -05:00
screentinker	501ffb11c1	feat(device-owner): tier foundation + QR provisioning + content-expiry & device enhancements (#168) ... Device-owner tier substrate + silent install, end-to-end QR provisioning (Android 12+ compliance, APK-derived checksum, URL pre-seed, zero-touch onboarding, guided a11y screen), content-expiry (#157) with player no-restart deferral, and the device-enhancement batch (#10/#12/#13/#14). Backward-compatible with 1.9.3 clients; all autonomous behaviors opt-in. QA + security review green. Closes #161, #157, #159.	2026-07-12 19:41:07 -05:00
Fabian Mendoza	34f1cb9e7c	feat(dashboard): version indicator + GHCR update check (#165) ... * feat(dashboard): version indicator + GHCR update check with admin panel - Add server/lib/ghcr-check.js: GHCR tag poller (36h cache, semver filter) - Extend /api/version with latest_version and update_available - Add POST /api/admin/check-update (force GHCR poll) - Add POST /api/admin/trigger-update (Docker compose or manual instructions) - Sidebar footer: version label + amber badge when update available - Admin > System: version comparison card with Check/Update buttons - 14 new tests (10 unit + 4 integration), 68/68 passing Closes #163 * fix(dashboard): gate trigger-update to platform-admin + add GHCR fetch timeout Review follow-up on #165 (the two blockers): - trigger-update runs `docker compose up -d` on the HOST via docker.sock (root-equivalent) but was behind requireAdmin, i.e. reachable by any workspace-level admin. On a multi-tenant host that's a customer, not the infra operator. Gate it with requirePlatformAdmin (DOCKER_UPDATE_ENABLED still gates it further). check-update stays requireAdmin — it's a read-only GHCR poll. - ghcr-check.checkNow had no fetch timeout. Node's global fetch has no default timeout, so a hung GHCR connection never settled — leaving `inFlight` set forever (the finally never ran), which wedged the background poller AND hung any awaited checkNow (/api/admin/check-update). Add a 10s AbortController timeout on both requests so the try/catch/finally always fire. All 405 server tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: ScreenTinker <hello@screentinker.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-10 22:40:06 -05:00
screentinker	1ebdb1f7a9	feat(ota): self-update kill switch — global, per-device, and MDM auto-detect (#166) ... Lets an operator (or an MDM) own updates instead of the app self-installing, which on managed panels shows a self-install confirm dialog over customer content (#155). Three layered controls: - GLOBAL (server): config.otaEnabled from OTA_ENABLED (default on). When off, /api/update/check returns update_available:false, reason:ota_disabled_global — the whole instance stops offering updates. - PER-DEVICE (server + dashboard): new devices.ota_enabled column (default 1). When 0, that device is never offered an update (reason:ota_disabled_device). A "Self-update (OTA)" toggle in the device settings flips it via PUT /api/devices/:id. - AUTO-DETECT (Android): UpdateChecker stands down entirely when a foreign device owner (an MDM/DPC) manages the panel — detected via getActiveAdmins() + not being device owner ourselves. Pure client-side, errs safe, needs no server change. The two server gates are enforced server-side so they cover EVERY client version, not just ones with the client-side stand-down. When OTA is off the device still reports its version (dashboard sees state); the MDM/operator owns the actual update. For an MDM-managed fleet (e.g. Pivot/MAXHUB), turn OTA off and let the MDM push the APK — the install-dialog race disappears from every angle. Tests: +2 (per-device gate + a real OTA_ENABLED=false server for the global gate); full server suite 393 pass; Android compiles. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-10 22:38:58 -05:00
BlazzzPlay	d474122334	Merge origin/main into feat/android-hidden-settings-menu ... Resolved conflict in server/db/database.js: kept both settings_pin migration (our change) and device_settings table migration (main's #150).	2026-07-09 20:09:58 -04:00
BlazzzPlay	58f27d56e8	fix(android): server-provisioned settings PIN replaces hardcoded 0000 ... - Remove stray brace that broke compilation (MainActivity line 985) - Server generates unique 6-digit PIN per device during pairing - PIN stored in encrypted SharedPreferences (ServerConfig.settingsPin) - Fallback: generate random PIN locally if server doesn't send one - Include settings_pin in device:paired on pair + reconnect - DB migration: settings_pin column on devices table - Hint changed from hardcoded 0000 to generic 'PIN' string	2026-07-09 19:05:24 -04:00
Fabian Mendoza	90b8cbb1e6	fix(preview): server-side preview sessions to bypass CSP (#151) ... * fix(preview): replace srcdoc with server-side preview sessions to bypass CSP Widget previews (clock, weather, etc.) were rendered via iframe.srcdoc, which inherits the dashboard CSP script-src 'self'. This blocked the inline scripts widgets need (setInterval for clock, fetch for weather), causing previews to show blank/static content. Replace srcdoc with ephemeral server-side preview sessions: - POST /api/widgets/preview-session — stores rendered HTML (Map, 5min TTL) - GET /api/widgets/preview-session/:id — serves the HTML via iframe src, bypassing CSP like the device render endpoint already does The old /api/widgets/preview endpoint is unchanged for backward compat. * fix(preview): add rate limiter for /preview-session route --------- Co-authored-by: BlazzzPlay <fabianma7@gmail.com>	2026-07-09 15:39:07 -05:00
ScreenTinker	8ad2258e7c	feat: app-ending signal (exit-signal contract v1) — server + APK + .wgt + /player ... Best-effort "last gasp" so Offline is annotated with WHY it went away — completing the liveness story. Categories: crashed (client uncaught-exception), clean_exit (client confident lifecycle-end, best-effort), silent (SERVER-inferred by absence — the honest catch-all for violent/external death incl. force-stop/MDM). SERVER: - device:exit socket handler + token-authed beacon POST /api/device/exit (reliable-on-unload). Both gated by liveness.sanitizeExitReason (honesty: only crashed/clean_exit accepted; 'silent'/unknown rejected). - offline_reason/offline_reason_at/offline_detail columns (additive migration). Clear-on-online (a reason is always THIS session's); offline transition COALESCEs to 'silent'. Pure annotation — offline detection and #148/liveness are untouched. Offline dashboard emits carry offline_reason + client_type. CLIENTS (canonical {reason,detail} shape): - /player: window error/unhandledrejection + pagehide(persisted=false) -> sendBeacon. - .wgt: same + BACK-key exit -> socket.emit + sendBeacon. - APK: global UncaughtExceptionHandler -> crashed (blocking beacon, chains to default); Service.onDestroy -> clean_exit (socket + bounded beacon). New ExitSignal.kt. onStop/onPause NOT wired (background != exit). Proven (Phase 3): per-category classification, nothing misclassified, external kill -> silent (never clean_exit), backgrounding emits no false exit, #148/reconnect-vs-exit intact. 382/382 suite green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-08 15:32:40 -05:00