The session list is ownership-scoped, and an emptied filter means none
The failure mode this rules out is an explicit request for no sessions answered with every sibling session in the workflow.
The rule
- A caller without authority to view any session sees only sessions they own: the ownership condition binds the list and its total count alike, on the default path and on the filtered path, so the
idsfilter can only narrow what the caller could already see. - Where the filter is present but every value in it parses away, the list answers an empty page with a total of zero; it must not fall through to the unfiltered list.
What it means
Ownership does not bind only the rows a caller can see; it binds the count that comes back beside them. A list scoped by ownership but a total taken from an unscoped count would tell a caller with no authority how many sessions exist in total — a narrower leak than the rows themselves, and an easy one to miss because the two numbers are computed by separate queries.
The ids filter cannot widen that scope. Naming a session id the caller
does not own returns nothing, not a 404 and not the session — the filter can
only narrow what ownership already allows, never substitute for it. And
where every value in the filter fails to parse, the answer is the same empty
page with a zero total, never the unfiltered list a naive empty-filter check
would fall through to.
Example
A workflow with two sessions, one per owner: what the total answers depends on which authority is asking, and it moves together with the rows.
12Naming another owner's session id in the filter, or a filter that parses away entirely, both reach the same floor:
0