github-mirrors/netris-nestri
1
0
Fork 0
mirror of https://github.com/nestriness/nestri.git synced 2026-09-19 09:15:19 +03:00
Code Issues Packages Projects Releases Wiki Activity

fix(api): say what the library check actually proves

Browse Source 
A library entry records the person, not the account the games were
synced from, and `POST /library/sync` is not even told which account a
list came from. So the ownership check added for session requests asks
"has somebody this person linked got this game?" and not "does the
account about to play own it?" — for the one Steam account most people
have those are the same sentence, and for two they are not.

Confirmed rather than reasoned about: a person with two Steam links, a
game synced at person level, and a request naming the second account is
accepted today.

The check stays, because it still turns a box that boots, tries to
launch and fails minutes later into an immediate refusal, and it never
refuses on account grounds that the data cannot support. What changes is
the comment, which claimed the stronger property, and a test that pins
the gap so it is found deliberately rather than by surprise.

Closing it properly means recording the linked account on a library
entry: a column, a sync contract that says which account a list belongs
to, a uniqueness rule per account rather than per person, and a backfill
with no correct answer for rows already written. That is a decision about
what a library is, and inferring it here would be the kind of modelling
taken by accident that this branch refuses elsewhere.
This commit is contained in:
Wanjohi
2026-09-04 22:27:20 +03:00
parent 51dabddbd8
commit 7bdca1240f
2 changed files with 51 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
apps/api/app/routes/session.ts
View File

@@ -137,18 +137,27 @@ export namespace SessionApi {
);
}
// A run launches as a Steam account that has to own the game, so
// a game outside the caller's library is a box that starts, tries
// to launch, and fails minutes later with nothing to point at.
// Refusing here is the same answer sooner.
// A game nobody has synced for this person is a box that starts,
// tries to launch and fails minutes later with nothing to point
// at. Refusing here is the same answer sooner.
//
// Told apart from a game that does not exist rather than hidden:
// the catalog is public, so there is nothing to hide, and "you do
// not own this" is the sentence a person can act on.
// not own this" is a sentence a person can act on.
//
// The library is a synced copy, so this refuses a game bought
// since the last sync. That is a staleness bug in the sync and
// not a reason to launch runs that cannot work.
// **This is a weaker check than the one that matters.** A run
// launches as one account, but a library entry records only the
// person, so what is verified is "somebody this person has linked
// owns it" and not "the account playing owns it". For the one
// linked account most people have those are the same sentence;
// for two they are not, and the second account can ask for a game
// only the first owns. Answering the real question needs the
// account recorded on the library entry, which is a decision
// about what a library *is* and not something to infer here.
//
// The library is also a synced copy, so this refuses a game
// bought since the last sync. Both gaps let a launch fail late;
// neither is a reason to start runs already known to fail.
const owned = await Library.findByUserAndGame({ userId, gameId: game.id });
if (!owned) {
throw new VisibleError(