[wp-trac] [WordPress Trac] #44157: the comments/[id] endpoints should have the same permissions checks as the comments endpoint

[WordPress Trac]

#44157: the comments/[id] endpoints should have the same permissions checks as the
comments endpoint
--------------------------+-----------------------------
 Reporter:  tharsheblows  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  REST API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  2nd-opinion   |     Focuses:
--------------------------+-----------------------------

Comment (by tharsheblows):

 To recap: for general users (users who do not have the `edit_posts`
 capability) the comments endpoint only lists comments which have been
 approved.

 It will throw an error for the whole list if there is a query on the posts
 (eg `wp-json/wp/v2/comments?post[]=x`) and the user doesn’t have
 permission to read one of them — ie if they can read all but one they’ll
 still get an error for the list. This should probably be fixed and those
 checks (read permission on the post and what to do if the post_id === 0)
 could be added to `get_items` with the comment simply not listed if it
 fails it. (It’s irrelevant here but worth noting.)

 Users without the `edit_posts` capability cannot search comments by author
 or author details which makes total sense. They also cannot search by the
 comment type and can only view comments of the type ‘comment’ (which is
 also null if you’re looking in the database, they’re the same) and they
 can’t search for unapproved comments.

 It was the comment_type check that I mentioned above — there’s no such
 check on the individual comment endpoint in `get_item` and it’s possible
 to iterate through them, picking up comments of all types including
 pingbacks and trackbacks. The attached patch illustrates this.

 The absence of a way to register_comment_type makes deciding what to do a
 bit more difficult. If people are using custom comment types, they’re
 rolling their own method most likely using `wp_insert_comment` and, I
 would assume, extending the comments controller in the REST API — the
 alternative is iterating through the endpoint to tease out the comments of
 the proper type.

 This seems a bit of edge case — someone using a custom comment type and
 then not extending the controller, and maybe it’s more correctly an edge
 case of an edge case, there are not a lot of people using custom comment
 types.

 I think that almost no one would be effectively scraping all of the
 individual comment endpoints for use in legitimate things and there might
 be unintended leakage of information by people who don’t realise those are
 public.

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