RTC: Check wp_user_id before accepting awareness update#11120
RTC: Check wp_user_id before accepting awareness update#11120chriszarate wants to merge 1 commit intoWordPress:trunkfrom
wp_user_id before accepting awareness update#11120Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
| */ | ||
| public function check_permissions( WP_REST_Request $request ) { | ||
| // Minimum cap check. Is user logged in with a contributor role or higher? | ||
| if ( ! current_user_can( 'edit_posts' ) ) { |
There was a problem hiding this comment.
@chriszarate While looking at this method, I'd like to check the accuracy of this line. I think it might end up blocking custom post types that use a non-default capability_type parameter.
2 participants
Trac ticket: https://core.trac.wordpress.org/ticket/64782
Using the built-in HTTP polling sync server, awareness state is accepted and stored after the user is authorized. This state is keyed against their sync client ID, which is randomly generated.
However, nothing prevents a user from spoofing another client's client ID, which is discoverable by inspecting network responses. By replaying a sync request with a different client ID, they could temporarily overwrite another client's awareness state.
This change prevents this spoofing by storing and checking the user's WordPress user ID to ensure it matches the initial update.
Backport of WordPress/gutenberg#76056