fix: authorize every read against its target object (#148)

[ifahimreza]

Closes #148

What

WordPress.org rejected the 1.0.0 submission with two findings. This PR fixes both.

The substantive one: read-tier abilities authorized the caller but never the object. Every read ability now resolves its target through one shared helper that checks read_post against it, and every list path filters what it enumerates. The Unsplash link in readme.txt gains a companion URL that resolves for their tooling.

Nothing changes for the normal setup. An administrator Application Password — how Saddle is actually connected — passes every new check, and the response shape is byte-identical to before.

Why

Their finding, on saddle/get-media:

The callback only checks the generic read capability, while get_media returns any attachment's metadata and URL without a per-attachment read_post authorization check.

Correct, and wider than the one ability. Read-tier abilities pass $cap = 'read' to Saddle_Capabilities::permission() — a capability every logged-in user holds, including a Subscriber. Any logged-in user can mint a core Application Password, and the MCP route only requires is_user_logged_in(). So a Subscriber-level credential reached the whole read surface: other authors' drafts, private posts, password-protected content, revision histories, and all of it enumerable.

The write side has guarded against exactly this since day one (authorize_write(), rule 4 of the wp-security-rules skill). The read side had the same idea implemented three times and applied to half the abilities.

How

One helper, not a fourth copy. Saddle_Abilities::require_readable_post() gains an input-key and post-type parameter, so get-post, get-page, get-media, get-blocks and list-post-revisions route through the same check that lint-page, render-node and verify-page already used. The byte-identical inline clone in blocks.php is deleted. get-preview-url stays deliberately stricter (edit_post for anything unpublished — it mints an unauthenticated URL) with a docblock saying so.

Password-protected posts refuse rather than blank. map_meta_cap never consults post_password, so read_post alone waves these through. Core blanks the content; Saddle returns raw post_content, which core only ever hands out in the edit context — so the threshold is core's own edit_post. Refusing rather than blanking because Saddle's reader feeds a writer on the same id: an agent handed content: "" concludes the page is empty and "fixes" it.

Lists need two controls, and perm => 'readable' is neither. Read against core rather than assumed:

• post_status => 'any' excludes only the internal statuses (register_post_status() derives exclude_from_search from internal, not protected), so it returns every author's drafts, pending, future and private.
• 'perm' => 'readable' is consulted at exactly one place (class-wp-query.php:2689) and applies only to an explicitly requested private. Against 'any' both $r_status and $p_status are empty, so it is a complete no-op. It is deliberately not used here — a query var that looks like the control but isn't is worse than none.

So, mirroring what core's REST controllers actually do: status_filter() gates the requested status on the post type's edit_posts (sanitize_post_statuses()), and collection() — the single chokepoint all three list paths already shared — drops rows failing read_post (get_items()). Both are needed: an Author holds edit_posts and may legitimately ask for drafts, and must still not receive someone else's. There is a test for exactly that case.

total counts dropped rows, and says so. Same inconsistency core lives with; recounting means a second unbounded query. What Saddle adds is a note on the response, because an agent handed a short page with no explanation retries it. Never fires for an administrator.

The Unsplash URL is a false positive, handled anyway. unsplash.com sits behind bot protection returning 401 to any user agent containing Mozilla and 200 otherwise — deterministic, three runs each. https://unsplash.com/privacy behaves identically and was not flagged, so a URL swap alone leaves a second landmine. The canonical terms and privacy URLs stay (the disclosure needs both; no mirror of the privacy policy exists) and Unsplash's own help-centre guidelines URL — 200 to every user agent — is added alongside.

Breaking

No public hook or filter changes. Five agent-visible behaviours do, none of them for an administrator credential:

• get-post / get-page / get-media / get-blocks / lint-page / render-node / verify-page return 403 for a target the connected account cannot read.
• Password-protected content returns saddle_password_protected (403) unless the account can edit_post it.
• list-posts / list-pages reject a status the account may not query (saddle_forbidden_status, 403); status: any now means "any status this account may see".
• Listings may return fewer items than per_page while total counts the omitted rows, with a note explaining it.
• list-post-revisions requires edit_post on the parent (matching core) and accepts post and page only; a CPT id that previously returned an empty list now returns 404.

Considered and left alone

get-user / list-users (read tier but gated on list_users, PII behind edit_users); get-option / list-options (admin tier, manage_options, plus guard_option()); get-template / get-global-styles / list-saved-patterns (public-facing presentation; the pattern query is publish only); Skills and Memory (both publish only, owner-authored instructions meant for any connected agent by design).

Testing

• composer test — 643 tests, 0 failures (612 before, 31 new). Every new case was run against the unfixed code first and confirmed failing for the reason it names.

• composer lint — 0 errors

• npm run build — committed bundle byte-unchanged (no JS in this diff)

• .pot regenerated — 6 new msgids, 0 removed; it was stale again

• php scripts/revendor-wp-mcp.php --check clean; the six execution functions grep clean outside the vendored adapter

• Verified in a real install over real HTTP, two Application Passwords on one site:

  call	subscriber	administrator
  get-post on a private post	403 saddle_forbidden	full content
  get-post on a draft	403 saddle_forbidden	full content
  get-media on that post's upload	403 saddle_forbidden	full metadata
  list-post-revisions	403 saddle_forbidden	200
  list-posts status=draft	403 saddle_forbidden_status	returns the draft
  list-posts (default)	published only	every status
  list-media	25 items / total 26 / note present	26 items / total 26 / no note key

• Plugin Check against the built zip — extracted zip staged under a folder named exactly saddle (never the symlinked dev tree), then restored. 0 errors. Three warnings, all pre-existing and previously recorded: one vendored-adapter hook name in class-saddle-mcp-compat.php, two dynamic hook names in class-saddle-integration-engine.php. The Tested up to error from the last submission is gone.

• Zip verified from the inside: no class-saddle-updater.php, no class-saddle-ecosystem.php, no tests/ / dist/ / root *.md / dotfiles, Stable tag still 1.0.0, outbound HTTP limited to the loopback self-check, Unsplash, and the OAuth client-metadata fetch.

CI note: main has been red since 2026-08-21 on Saddle_Skills_Test::test_the_playbook_adapts_step_two_to_a_classic_theme (issue #145, CI-only, does not reproduce locally). This branch inherits it. That failure is unrelated to this diff.

[ifahimreza]

CI: red on the inherited #145 failure only.

All six PHPUnit cells report Tests: 643, Assertions: 2574, Failures: 1, and the one failure is the same on every cell:

1) Saddle_Skills_Test::test_the_playbook_adapts_step_two_to_a_classic_theme

That is #145 — red on main since 2026-08-21, CI-only, does not reproduce locally. Every one of the 31 new tests in this PR passes on PHP 8.1/8.2/8.3 × WP 6.9/latest. PHPCS passes.

Not claiming green. This branch cannot go green until #145 is fixed.