Skip to content

fix(group-subscriptions): tighten authorization on the REST routes - #1023

Open
jason10lee wants to merge 2 commits into
mainfrom
fix/group-subscription-permission-checks
Open

fix(group-subscriptions): tighten authorization on the REST routes#1023
jason10lee wants to merge 2 commits into
mainfrom
fix/group-subscription-permission-checks

Conversation

@jason10lee

Copy link
Copy Markdown
Contributor

All Submissions:

Changes proposed in this Pull Request:

The group-subscription REST routes share one permission callback, and it could resolve an unauthenticated caller as authorized under a state the data layer can reach on its own. This makes an unresolved caller fail closed, and it narrows the one route in the namespace that answers about the site's readers instead of about a subscription.

Three of the four changes establish the same invariant from different places: an unresolved identity is never an authorized one. Any one of them closes the path, and together a regression in one is still not a grant. The guard in the shared callback turns away nothing that works today, which is what makes it cheap to keep.

The fourth is the narrowing. The member search answers about the site's user records, not about the subscription named in the request, so managing a group is the wrong authorization for it. Only the subscription admin screen calls that route; the reader-facing My Account bundle uses the rename and invite-link routes. For store staff, nothing changes.

We weighed two alternatives. The first was narrowing the search instead of closing it, by restricting non-staff callers to an exact-address lookup. We drafted that and rejected it: it leaves the route reachable by a population with no UI for it, and an exact lookup still answers whether a given address has an account here. The second was gating the two other admin-only routes the same way. We left that out, because neither answers about anything beyond the subscription the caller was already authorized for. That is hardening, not a fix, and it would remove a capability a manager may be intended to have.

Deliberately out of scope: what a group subscription should become when its owner no longer exists. This makes that state safe without deciding it, and it does not repair records already in it. Both are filed separately.

One test asserted the behavior the first change removes, so that assertion is updated here instead of worked around.

Detail is in https://linear.app/a8c/issue/NPPM-3203 and https://linear.app/a8c/issue/NPPM-3200.

How to test the changes in this Pull Request:

  1. On a site with Access Control enabled and WooCommerce Subscriptions active, open a group subscription in wp-admin and search for a reader to add. The search returns matching reader accounts.
  2. As that group's owner, open My Account and rename the group. The new name saves.
  3. As the same owner, generate an invite link for the group. The link generates.

The refusal paths are covered by unit tests added here.

Other information:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes, as applicable?
  • Have you successfully run tests with your changes locally?

Full newspack-plugin suite green (3902 tests, 11026 assertions), phpcs clean, and the three manual steps above were driven on an isolated env.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The authorization tightening is coherent across layers and is backed by targeted unit tests, with only minor doc wording noted.

Pull request overview

This PR hardens the newspack-plugin group-subscription REST API authorization by ensuring an unresolved/anonymous identity is never treated as authorized, and by restricting the “search users” endpoint to store staff only (since it answers about site user records rather than a specific subscription).

Changes:

  • Fail-closed authorization for group-subscription REST routes by explicitly rejecting unauthenticated requests and by preventing user ID 0 from ever matching an ownerless subscription.
  • Restrict /search-users permissions to manage_woocommerce users (store staff) rather than group managers.
  • Update and extend unit coverage for ownerless subscriptions and for the narrowed search-users permissions.
File summaries
File Description
plugins/newspack-plugin/tests/unit-tests/plugins/woocommerce-subscriptions/group-subscription/class-group-subscription-api.php Adds REST dispatch tests for anonymous/ownerless and admin-only search behavior; ensures feature flag is set for route registration.
plugins/newspack-plugin/tests/unit-tests/content-gate/group-subscriptions.php Updates expectations for manager resolution and adds coverage for ownerless subscriptions and unauthenticated callers.
plugins/newspack-plugin/includes/plugins/woocommerce-subscriptions/group-subscription/class-group-subscription.php Ensures manager resolution doesn’t seed a phantom manager (0) and guards user_is_manager against unauthenticated IDs.
plugins/newspack-plugin/includes/plugins/woocommerce-subscriptions/group-subscription/class-group-subscription-api.php Adds an anonymous guard in the shared permission callback and switches /search-users to an admin-only permission callback.
Review details
  • Files reviewed: 4/4 changed files
  • Comments generated: 1
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jason10lee
jason10lee marked this pull request as ready for review September 3, 2026 11:32
@jason10lee
jason10lee requested a review from a team as a code owner September 3, 2026 11:32
@dkoo dkoo self-assigned this Sep 3, 2026

@dkoo dkoo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jason10lee thanks for the tightening here! I tested and encountered no issues or regressions, and the explicit handling for unresolved users and the additional admin permission checks are well-documented and make sense to me.

@github-actions github-actions Bot added [Status] Approved Pull request has been approved and removed [Status] Needs Review labels Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Status] Approved Pull request has been approved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants