[wp-trac] [WordPress Trac] #59875: Revisions controller: get_item can return a revision whose parent does not match the `parent` route fragment

[WordPress Trac]

#59875: Revisions controller: get_item can return a revision whose parent does not
match the `parent` route fragment
--------------------------------------+------------------------------
 Reporter:  ramonopoly                |       Owner:  adamsilverstein
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  REST API                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-unit-tests has-patch  |     Focuses:  rest-api
--------------------------------------+------------------------------
Description changed by ramonopoly:

Old description:

> When fetching a single revision from the [https://github.com/WordPress
> /wordpress-develop/blob/trunk/src/wp-includes/rest-api/endpoints/class-
> wp-rest-revisions-controller.php WP_REST_Revisions_Controller], it's
> possible for `get_item` to return a revision whose parent does not match
> the `parent` in the REST URL.
>
> For example:
>
>  '/wp/v2/posts/${ someParent }/revisions/${ revisionOfSomeOtherParent }'
>

> So long as `someParent` has a matching post type, and
> `revisionOfSomeOtherParent` is a revision post type, I'll get the
> revision object of `revisionOfSomeOtherParent`, whose parent is another
> id.
>
> The consequence is that for any post type, I can return the revision of
> different parent post of that same type just by knowing the revision's
> post ID.
>

>
> It's a bit of an edge case but one, perhaps, that could be guarded
> against for example by checking that `parent.id === revision.parent` or
> something.
>
> The risk is that there might be some sites that, for whatever reason,
> probably unintentionally, are expecting values back from a mismatched
> combination of parentId and revisionId.
>
> The argument for dismissing this concern is that, in such as case, the
> URL is not representational of the resource, and so it is not RESTful.
>
> What do folks think?
>

> First noticed here:
> https://github.com/WordPress/gutenberg/pull/55827#discussion_r1385977711
>

> Related Slack discussion:
> https://wordpress.slack.com/archives/C02RQC26G/p1699504213232439

New description:

 When fetching a single revision from the [https://github.com/WordPress
 /wordpress-develop/blob/trunk/src/wp-includes/rest-api/endpoints/class-wp-
 rest-revisions-controller.php WP_REST_Revisions_Controller], it's possible
 for `get_item` to return a revision whose parent does not match the
 `parent` in the REST URL.

 For example:

  '/wp/v2/posts/${ someParent }/revisions/${ revisionOfSomeOtherParent }'


 So long as `someParent` has a matching post type, and
 `revisionOfSomeOtherParent` is a revision post type, I'll get the revision
 object of `revisionOfSomeOtherParent`, whose parent is another id.

 The consequence is that for any post type, I can return the revision of
 different parent post of that same type just by knowing the revision's
 post ID.



 It's a bit of an edge case but one, perhaps, that could be guarded against
 for example by checking that `parent.id === revision.parent` or something.

 The risk is that there might be some sites that, for whatever reason,
 probably unintentionally, are expecting values back from a mismatched
 combination of parentId and revisionId.

 The argument for dismissing this concern is that, in such as case, the URL
 is not representational of the resource, and so it is not RESTful.

 What do folks think?


 First noticed here:
 https://github.com/WordPress/gutenberg/pull/55827#discussion_r1385977711


 Related Slack discussion:
 https://wordpress.slack.com/archives/C02RQC26G/p1699504213232439

 Props to @andrewserong for helping to track down the bug

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59875#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform