VideoPress: use user token for video deletion API requests#47128
VideoPress: use user token for video deletion API requests#47128
Conversation
|
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! |
There was a problem hiding this comment.
Pull request overview
This pull request fixes Activity Log attribution for VideoPress video deletions by switching from blog token to user token authentication. When a VideoPress video is deleted from a Jetpack site, the wp.com API request now carries the acting user's identity, ensuring proper attribution in Activity Log entries.
Changes:
- Switch video deletion API requests from blog token to user token authentication
- Add explicit
'rest'base_api_path parameter to maintain correct API endpoint behavior - Update changelog to document the fix
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| projects/packages/videopress/src/class-attachment-handler.php | Changed delete_video_wpcom to use user token (wpcom_json_api_request_as_user) instead of blog token (wpcom_json_api_request_as_blog) for deletion API requests, with explicit 'rest' base_api_path |
| projects/packages/videopress/changelog/fix-videopress-deletion-attribution | Added changelog entry documenting the bug fix for Activity Log attribution |
Code Coverage SummaryThis PR did not change code coverage! That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷 |
The video deletion endpoint was called with a blog token (wpcom_json_api_request_as_blog), which carries no user identity. This caused the wp.com Activity Log to record the deletion without actor attribution. Switching to wpcom_json_api_request_as_user ensures the request carries the deleting user's identity. Explicitly passes 'rest' as base_api_path since the two methods have different defaults (_as_blog defaults to 'rest', _as_user defaults to 'wpcom'). This is safe because non-connected users are already blocked from deleting VideoPress attachments via disable_delete_if_disconnected.
cba4ed4 to
50dfdd5
Compare
Fixes https://linear.app/automattic/issue/VIDP-219
Proposed changes:
Client::wpcom_json_api_request_as_blogtoClient::wpcom_json_api_request_as_userinAttachment_Handler::delete_video_wpcom(), so that the VideoPress video deletion API request carries the acting user's identity.'rest'asbase_api_pathsince_as_userdefaults to'wpcom'while_as_blogdefaults to'rest'.Context:
When a VideoPress video is deleted, the Jetpack site calls the wp.com
/videos/{guid}/deleteendpoint. Previously this used a blog token (_as_blog), which carries no user identity. On wp.com, the endpoint callswp_delete_attachment(), which firesdeleted_postlocally — and the WPCOM Sync Listener captures this event with an empty actor (user_id=0). This Activity Log entry preempts the Sync event from the Jetpack site that carries the correct user data, resulting in the deletion appearing with no attribution in the Activity Log.Switching to
_as_userensures the API request is authenticated with the deleting user's token, so the wp.com-side activity is properly attributed.This is safe because non-connected users are already blocked from deleting VideoPress attachments via
disable_delete_if_disconnected, which strips thedelete_postcapability whenData::can_perform_action()returns false.Other information:
Does this pull request change what data or activity we track or use?
No. The same API request is made — only the authentication method changes from blog token to user token.
Testing instructions: