Enforce per-page read permission on the Subject, Layout, and RDF read endpoints

[alistair3149]

Fixes #1046

The Subject, Layout, RDF, and schema-name read endpoints answered with data from pages the caller may not read. MediaWiki's REST framework checks only the wiki-global read right, so a fully private wiki was protected wholesale while partially restricted setups (page protection with read-restriction extensions, restricted namespaces, read whitelists, permission-filtered farms) leaked both Subject data and page existence. The POST /subject/{id}/validate endpoint additionally oracled Subject existence outright (404 for absent, 200 for present).

Every read path now enforces the caller's per-page read permission via Authority::authorizeRead( 'read', $title ) — the binding check that runs the expensive permission hook ACL extensions rely on. The pre-existing Schema and Mapping gates used probablyCan, which core documents as unfit for access control (it skips that hook), and carried a comment claiming the inner lookup applies a per-user read check; RevisionRecord::FOR_THIS_USER filters revision-deletion suppression only, so no such check existed. Both gates are upgraded and the comment corrected.

Denials are deliberately indistinguishable from absent data. Page and revision IDs are sequential integers, and readable Subjects hand out the IDs of Subjects they reference, so any distinguishable denial (a 403, a different message) is a sweepable oracle over which pages are restricted. Each endpoint routes denial through its existing miss shape, byte-identical:

Endpoint	Denied response
GET /subject/{id} (incl. expand=)	200 {"subject":null}
GET /subject/{id}?revisionId=N (page of N unreadable)	404 Revision not found: N
GET /page/{id}/subjects (incl. expand=)	200 + empty subject map
GET /page/{id}/rdf	404 No NeoWiki data found for page: <id>
POST /subject/{id}/validate	404, same message as an absent Subject
GET /layout/{name}	200 {"layout":null}
GET /schema/{name}	200 {"schema":null}
GET /layouts, GET /schemas, GET /schema-names/{search}	denied rows omitted

Referenced Subjects on unreadable pages are omitted from expand=relations responses; the readable page's own relation statements still show the opaque target IDs, which are that page's content. Every denial is logged at info level to the NeoWiki channel with page and performer, so the suppressed error stays diagnosable server-side. This diverges from core REST's 403 convention on purpose: core's endpoints are title-keyed and page existence by title is already public there; ours are keyed by dense integer IDs and by Subject IDs that leak through relations.

Architecturally this completes the #1003 split with a third quadrant: SubjectReadAuthorizer (binding, side-effect-free apart from rate-limit accounting — no read bucket exists by default) joins SubjectPermissionHints and SubjectWriteAuthorizer on AuthorityBasedSubjectAuthorizer, and every PageId-keyed gate goes through it. Unlike the write side there is no global-right fallback: content is only reachable through a resolved page, so an unresolvable page denies. Name-keyed Persistence lookups (Layout, schema names, the Schema/Mapping caches) hold an Authority directly, as CachingSchemaLookup already did. Where a Subject's owning page does not resolve in the graph, GetSubjectQuery treats it as readable — that case is reachable only from its ?revisionId= branch, whose page the handler has already authorized — while GetPageSubjectsQuery, where the case is unreachable, fails closed so a future non-graph lookup cannot silently bypass the gate. The validate endpoint now resolves the owning page once and denies before reading any slot content, which also removed a duplicate graph query, as did the single resolve serving both the gate and expand=page in GetSubjectQuery.

The issue's premise that the read paths "apply RevDel audience checks (FOR_THIS_USER)" was wrong in a way that matters: the Subject paths pass no audience at all (default FOR_PUBLIC, which is stricter), and FOR_THIS_USER was never a read gate anywhere. The issue text should be corrected accordingly.

Verification

Every gate is pinned by tests that were proven load-bearing by mutation during development: flipping the denying authority to permissive (or reverting a gate to probablyCan, or changing the 'read' action string) fails a test for each gate. Denial tests assert byte-identity with the absent shape, not just status codes. make cs (phpcs + phpstan) clean; all touched suites green, including broad filter=Subject (545 tests) and filter=Schema (286 tests).

Verified end-to-end on the dev wiki (anonymous caller, one page denied via a getUserPermissionsErrors hook, control page unrestricted): the full denied matrix above reproduced exactly, the control page stayed fully visible, schema-name enumeration omitted the denied Schema, and lifting the restriction restored full responses.

Manual check

A sitewide read lockdown cannot exercise these gates — MediaWiki's REST framework rejects all routes on the wiki-global read right first. Use a targeted per-page denial:

1. Append to Docker/LocalSettings.local.php (edit the file in place, e.g. with cat >> — replacing it breaks the bind mount):

   $wgHooks['getUserPermissionsErrors'][] = static function ( $title, $user, $action, &$result ) {
       if ( $action === 'read' && $title->getDBkey() === 'ACME_Amsterdam_HQ' ) {
           $result = 'badaccess-group0';
           return false;
       }
       return true;
   };

   No container restart needed.
2. As an anonymous caller (demo data: page 30 = ACME Amsterdam HQ, main Subject s1demo7aaaaaaa4):
   • GET <wiki>/w/rest.php/neowiki/v0/page/30/subjects → 200 {"pageId":30,"mainSubjectId":null,"subjects":[]}
   • GET .../page/30/rdf → 404 No NeoWiki data found for page: 30
   • GET .../subject/s1demo7aaaaaaa4 → 200 {"subject":null}
   • POST .../subject/s1demo7aaaaaaa4/validate (body {"label":"x","statements":{}}) → 404 Subject not found: s1demo7aaaaaaa4
   • Any other page with Subjects → unaffected.
3. Remove the hook → full data returns immediately.

Deferred

Documented in the new docs/api/rest-api.md Permissions section; each has its own follow-up issue.

• {{#cypher_raw}} / nw.query parse-time graph reads check nothing (Parser-time Cypher (#cypher_raw / nw.query) runs with no permission check #1059) — a full read bypass on graph-enabled wikis, separate subsystem.
• GET /subject-labels still enumerates labels from restricted pages (GET /subject-labels leaks labels of Subjects on unreadable pages #1060) — needs a Cypher page-traversal, a limit cap, and per-result filtering.
• Write-path existence oracle (Subject write endpoints oracle page existence (403 vs 201 no-op) #1061) — page-id-keyed write endpoints answer 403 for unreadable pages vs 201 no-op for nonexistent page IDs.
• totalRows count oracle on GET /layouts / GET /schemas (totalRows count oracle on GET /layouts and GET /schemas #1062) — arrays omit denied rows but the count still includes them.
• Parse-path read authority (Parse-path Schema/Mapping reads vary by user but the parser cache does not (ADR) #1063) — Lua schema reads vary by user while the parser cache does not; pre-existing tension, unchanged here, ADR-shaped.

Directed by @alistair3149; gate method, scope, and denial shape were each decided explicitly in review with them, including the deliberate divergence from core REST's 403 convention.
Context: the NeoWiki codebase, MediaWiki Authority/PermissionManager/REST internals, the #101 audit history, and multi-agent implementation with per-task spec + quality reviews, mutation-tested gates, an independent final review, and a live smoke test.
_{Written by Claude Code, Fable 5}

🤖 Generated with Claude Code