Make WordPress Core

Opened 14 months ago

Closed 10 months ago

Last modified 10 months ago

#57745 closed defect (bug) (fixed)

REST API post update fails with unchanged but auth-restricted meta value

Reported by: kadamwhite's profile kadamwhite Owned by: kadamwhite's profile kadamwhite
Milestone: 6.3 Priority: normal
Severity: normal Version: 6.1.1
Component: REST API Keywords: has-patch has-unit-tests commit
Focuses: Cc:


Originally flagged by @ckoerner

If there is a meta value registered for a REST object which requires authentication to change, updates to the parent object will fail on save even if the meta value is not being updated.


  1. Register a post meta value, with show_in_rest, which defines a custom auth_callback which requires elevated permissions
  2. Open a post in the block editor (you can use the selectors to validate the meta value is set to its default value)
  3. Trigger a post save
  4. The post updates, because post data is processed before meta; but the PUT request will fail with a 403, because the (unchanged) meta value auth_callback is not satisfied

What is expected: A save to a post with no changes to the passed data would succeed, and authentication for a meta field would only be invoked if the passed value differs

Note: this touches the same piece of code as #55600, and the goals of these two tickets may be incompatible. If a meta field has authentication required and a default value, when the REST response for that post is received which includes the default meta value and then PUT back to the server, this ticket argues that the unchanged value should be ignored and the authentication callback not invoked. #55600 argues that a default value should be written to the database on save, which would require an authentication check even if the value being sent back is the default.

Change History (10)

This ticket was mentioned in PR #4091 on WordPress/wordpress-develop by kadamwhite.

14 months ago

  • Keywords has-patch has-unit-tests added

#2 @kadamwhite
14 months ago

@TimothyBlynJacobs @spacedmonkey I'd appreciate a second opinion about this ticket versus #55600. I feel personally that we should _not_ write a default meta value to the database if no meta value is present yet — that is, fix this issue described here, and close #55600. Because if I'm reading them correctly they feel incompatible with each other. However, I may be missing something.

#3 @TimothyBlynJacobs
14 months ago

This seems like a sensible approach to me. I'm inclined to agree that we shouldn't be writing the default to the database. But, I don't think fixing this necessarily blocks #55600. We could still omit writing the default value to the database if the user doesn't have permission to update that field.

This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.

13 months ago

#5 @kadamwhite
13 months ago

  • Milestone changed from Awaiting Review to 6.3

#6 @spacedmonkey
10 months ago

  • Keywords commit added

Marking this as ready to commit. Go ahead and commit @kadamwhite

This ticket was mentioned in Slack in #core-committers by kadamwhite. View the logs.

10 months ago

#8 @kadamwhite
10 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

kadamwhite commented on PR #4091:

10 months ago

Merged in / 507cab8d6f5d469c6b0131bb07a45eb6f0c6724e

#10 @spacedmonkey
10 months ago

Does this need a dev note @kadamwhite ?

Note: See TracTickets for help on using tickets.