mr.zeroandClaude Opus 5
26c7aa9be1
ci/woodpecker/push/woodpecker Pipeline was successful
A store with paid titles had nothing to tell this client and no way for it to listen: the catalog carried no price, no entitlement and no sign-in, so a gated download could only come back 403 and leave the window guessing why. The knowledge belongs on the server, not here. This client serves whichever catalog a registry names, so anything it knew about a particular shop would be a rule that breaks every other one. WarpEngine 0.5 answers GET /api/service with what it offers and puts an `access` block on every entry; this reads both. There is no store name anywhere in the diff. - **0.5 is a dialect of its own**, the older shape with `access` added. The version list is exhaustive over the selector, so adding it was a compile error until somebody said what it reads like — which is what that switch is for. - **A card shows a price and a Buy button** when a title is not yours, opening the store's own page. Buying stays in a browser: a checkout rebuilt here would be a second place to get card handling wrong. - **Signing in is the device grant**: a short code, the person's own browser, and no password crossing this window. The token goes in the OS keychain through safeStorage — one per store — and where no keychain exists it is not stored at all rather than written out in the clear. - **Owned / To buy** join the categories, since owning something is not the same as having installed it. Three things worth stating about the shape: The bearer token stops at the origin that issued it. A gated download redirects to signed storage — often somebody else's host — and some object stores refuse a request outright when an Authorization header arrives alongside the signature. An absent access block is not "free". It is an engine too old to have an opinion, and only one of those two is a reason to offer somebody a sign-in, so the three states are kept apart all the way to the card. state.json does not carry entitlement. Whether somebody may download a title is the server's answer to a question asked now; a copy on disk would go stale on the next purchase or refund, and a stale yes is the dangerous direction. A store with no sign-in shows none, and every WarpEngine before 0.5 is such a store: no Account block, no prices, no new categories. The smoke test against the live catalog reports exactly that — `sign-in: not offered`, `access: open:13`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
65 lines
2.7 KiB
TypeScript
65 lines
2.7 KiB
TypeScript
import type { SelectedGame } from './SelectedGame'
|
|
|
|
/**
|
|
* One title as it exists on this machine: what was written, and where.
|
|
*
|
|
* This is the shape `state.json` carries, keyed `<scope>:<name>`. Every path in it
|
|
* is something the store put there and may therefore delete — which is why an
|
|
* uninstall reads the record rather than guessing at paths.
|
|
*
|
|
* The catalog's `access` block is deliberately *not* part of it. Whether somebody may
|
|
* download a title is the server's answer to a question asked now; a copy of it on disk
|
|
* would go stale the moment a purchase or a refund happened, and a stale "yes" is the
|
|
* dangerous direction. What is installed stays installed either way.
|
|
*/
|
|
export interface InstalledRecord extends Omit<SelectedGame, 'access'> {
|
|
/** The unpacked archive's directory; null for a hosted entry, which has none. */
|
|
readonly payload: string | null
|
|
readonly executable: string | null
|
|
/** `bundle` for a macOS `.app` the archive already contained, `exe` for a binary. */
|
|
readonly executableKind: string | null
|
|
readonly icon: string | null
|
|
/** The menu entry actually written, which is not always the one intended. */
|
|
readonly menuEntry: string | null
|
|
readonly url: string | null
|
|
}
|
|
|
|
/**
|
|
* The scope a state record belongs to.
|
|
*
|
|
* `scope` is what the engine writes today. `system` is what the Batocera store
|
|
* wrote before the shared core existed, and there the two were the same string —
|
|
* so an installed machine keeps working without a migration.
|
|
*/
|
|
export function recordScope (scope: string | null, system: string | null): string {
|
|
return scope ?? system ?? ''
|
|
}
|
|
|
|
/** Two scopes may both carry a game called `foo` — key on both. */
|
|
export function gameKey (record: { readonly name: string; readonly scope: string }): string {
|
|
return `${record.scope}:${record.name}`
|
|
}
|
|
|
|
/** Resolve user-typed `name` or `scope:name` arguments to state keys. */
|
|
export function matchStateKeys (
|
|
installed: ReadonlyMap<string, InstalledRecord>,
|
|
names: readonly string[]
|
|
): readonly string[] {
|
|
const wanted = new Set(names.map((name: string): string => name.toLowerCase()))
|
|
const keys: string[] = []
|
|
for (const [key, record] of installed) {
|
|
if (wanted.has(key.toLowerCase()) || wanted.has(record.name.toLowerCase())) keys.push(key)
|
|
}
|
|
return keys
|
|
}
|
|
|
|
/** Keep only the games the user named, by bare name or `scope:name`. */
|
|
export function limitToNames (
|
|
games: readonly SelectedGame[],
|
|
names: readonly string[]
|
|
): readonly SelectedGame[] {
|
|
const wanted = new Set(names.map((name: string): string => name.toLowerCase()))
|
|
return games.filter((game: SelectedGame): boolean =>
|
|
wanted.has(game.name.toLowerCase()) || wanted.has(gameKey(game).toLowerCase()))
|
|
}
|