ActivityPub: Widen Reader auth shim to user-actor routes#49100
ActivityPub: Widen Reader auth shim to user-actor routes#49100pfefferle wants to merge 1 commit into
Conversation
The Jetpack-signed Reader-auth shim previously accepted only blog-actor routes (`actors/0/...`) and required the AP site to be in `blog` or `actor_blog` mode. The wpcom Reader also signs requests for user-actor routes when a Jetpack user token is available, so those calls were being rejected even though Rest_Authentication had installed the matching wpcom user. Two changes: - `is_target_route` now accepts any user id (`actors/\d+/...`). The AP plugin's own `verify_owner` enforces actor identity natively (current-user equality for user actors; BLOG_USER_ID + user_can_act_as_blog for the blog actor), so the shim does not need to repeat that check. - The `is_blog_mode` early-return in the permission callback is now scoped to blog-actor routes via a new `route_is_blog_actor` helper. User-actor existence is independent of `activitypub_actor_mode`, so the blog-mode gate is not relevant there. Tests updated to cover the new positive cases (user-actor inbox/outbox in `actor` and `actor_blog` modes) and to keep the existing negative case (blog-actor route in `actor`-mode still abstains).
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: The Jetpack plugin has different release cadences depending on the platform:
If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
Code Coverage SummaryCoverage changed in 1 file.
|
See CM-776
Proposed changes
The Jetpack-signed Reader-auth shim previously accepted only blog-actor routes (
actors/0/...) and required the AP site to be inblogoractor_blogmode. The wpcom Reader also signs requests for user-actor routes when a Jetpack user token is available, so those calls were being rejected even thoughRest_Authenticationhad installed the matching wpcom user.jetpack_activitypub_reader_auth_is_target_route()now accepts any user id (actors/\d+/...), not justactors/0/.... The AP plugin's ownActivitypub\Rest\Verification::verify_ownerenforces actor identity natively (get_current_user_id() === (int) $user_idfor user actors;BLOG_USER_ID + user_can_act_as_blog()for the blog actor), so the shim does not need to repeat that check — its role is bypassing the OAuth bearer requirement on Jetpack-signed calls.is_blog_modeearly-return injetpack_activitypub_reader_auth_check_permission()is now route-scoped via a newjetpack_activitypub_reader_auth_route_is_blog_actor()helper. User-actor existence is independent ofactivitypub_actor_mode, so the blog-mode gate is only relevant when the route targets the blog actor.is_blog_modepurpose,is_target_routerationale).Related product discussion/links
Does this pull request change what data or activity we track or use?
No.
Testing instructions
Unit tests cover the new behaviour. Run them with:
The suite in
projects/plugins/jetpack/tests/php/3rd-party/Jetpack_ActivityPub_Reader_Auth_Test.phpwas extended with:actormode, user-actor outbox inactor_blogmode (test_check_permission_grants_user_actor_in_user_mode,test_check_permission_grants_user_actor_in_actor_blog_mode).is_target_routeaccepting non-zero user ids (user_id 1,user_id 42,users/7alias).route_is_blog_actorhelper (positive foractors/0/, negative foractors/5/, defensive against non-request payloads).test_check_permission_null_for_blog_actor_in_user_mode) — a blog-actor route on a pureactor-mode site still abstains, since no blog actor exists there.End-to-end manual verification (on a Jetpack-connected AP site in
actormode, signed-in admin via the wpcom Reader):/wp-json/activitypub/1.0/actors/<your-user-id>/inbox— previously 401, now serves the user's inbox./wp-json/activitypub/1.0/actors/<your-user-id>/outboxwith a Note — previously 401, now publishes./wp-json/activitypub/1.0/actors/0/inboxon the sameactor-mode site — still returns 401, because the blog actor doesn't exist.Local gates run