A listing asked for a user that is not there answers with nothing #64
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A listing asked on behalf of a user that is not there answers with nothing.
RequestHelpers.GetUserId(RequestHelpers.cs:67) does not check that the userexists. It falls back to the caller when none is named, forbids a non-admin
naming somebody else, and otherwise returns the id as given — so a valid guid
naming no row is passed straight through, and the routes that take it go on to
answer as though no user narrowed them.
Measured against a production library, with a guid no user carries:
/Persons?userId=<unknown>/Search/Hints?userId=<unknown>&searchTerm=blue/Genres?userId=<unknown>/Items?userId=<unknown>/Itemsagrees becauseItemsControllerlooks the user up for itself andrefuses. The by-name and search routes do not, and this server narrows every one
of them to a user that has no libraries — which selects nothing.
Found replaying the committed scenarios against a library that is not the
reference fixture, so the user id they name does not exist here. That is what
made it visible, but the behaviour is not about fixtures: any client holding a
stale user id sees an empty library rather than the answer upstream gives.
Fixed. Upstream's rule is that an id it cannot resolve narrows nothing,
where this server narrowed to a user that has no libraries — which selects
nothing.
LibraryManager.AddUserToQuery(LibraryManager.cs:1994) is called only whenquery.User is not null, and only it setsTopParentIds. So a null user meansno library filter at all. The routes divide three ways, all read from the C#:
/Items/Items/{id}/Collectionsif (user is null) return Unauthorized()before the item lookup/Persons,/Genres,/MusicGenres,/Studios,/Artists,/Years,/Search/Hints,/Items/Filters2Fixed outright in the
bundlescenario:/Items/{id}/Collectionsnow 401,/Items/Filters2all three lists,/Personscount 0 → 32576,/Search/Hints0 → 24 hints.
A bonus that was not part of this issue:
/Items/Filters2was returning fourempty lists for every user, not only unknown ones. For a real user it now
agrees with upstream exactly — Genres 20, AudioLanguages 16, SubtitleLanguages
51, Tags 0.
Ten tests, of which three are deliberate guards that pass either way:
/Itemsstill 404s, an unnamed id still reads the caller, and a restricted account still
sees only its own library. Removing narrowing for a real user is the regression
this could most easily have caused.
The scenario count rose to 23 because two pre-existing defects were invisible
while these routes answered emptily — filed as #67 and #68.