[wp-trac] [WordPress Trac] #38412: cannot update or delete user, term or comment meta via REST API

[WordPress Trac]

#38412: cannot update or delete user, term or comment meta via REST API
--------------------------+------------------------
 Reporter:  tharsheblows  |       Owner:  rmccue
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  4.7
Component:  REST API      |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------

Comment (by tharsheblows):

 @jeremyfelt yes, pretty much! I've just looked back at it -  I'm sorry I
 didn't realise this earlier and whilst I think it's an issue, it might not
 be.

 It's my understanding that the `auth_{$object_type}_meta_{$meta_key}`
 filter is, if set, what determines whether a user can update a meta key.
 If it isn't set, then there's a check to see if it's a protected meta key
 and then, if it's not a protected meta key, then you can update the meta
 key if you can update the object type.

 (The `auth_callback` in `register_meta` is one thing that adds this
 filter.)

 So the check should be:
  1. is there a filter on `auth_{$object_type}_meta_{$meta_key}`)?
   *  Yes -> do whatever it says
   *  No -> proceed
  2. is the meta key protected?
   * Yes -> set the capability to `edit_{$object_type}_meta`
   * No -> set the capability to `edit_{$object_type}`

 It currently doesn't work like this, the filter is applied after the
 `edit_{$object_type}` capability is set so you can't allow a user who
 doesn't have that capability to update meta even if you'd like to do so.

 The change would affect this edge case: if someone is using
 `current_user_can( 'edit_post_meta' )` with a filter on
 `auth_{$object_type}_meta_{$meta_key}` that returns true but they really
 don't want the person to update the post meta so are relying on the fact
 that they don't have the edit_post capability, then that will change and
 that person will be able to update the post meta. It will only affect
 post_meta because that's the only filter in there currently.

 It's a straightforward fix and I have tests for the auth_callback filter
 that I can add to the capabilities tests but thought I'd ask about it now
 before cluttering up with another patch. One thing it does require is
 setting the `auth_callback` default to `null` rather than `__return_true`
 in `register_meta`. I don't think that would be an issue but want to
 mention.

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