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

[kadamwhite]

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.

Example:

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 wp.data 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.

Trac ticket: https://core.trac.wordpress.org/ticket/57745

[kadamwhite]

@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.

[TimothyBlynJacobs]

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.

[spacedmonkey]

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

[kadamwhite]

Fixed in https://core.trac.wordpress.org/changeset/56075

Merged in https://core.trac.wordpress.org/changeset/56075 / 507cab8d6f5d469c6b0131bb07a45eb6f0c6724e

[spacedmonkey]

Does this need a dev note @kadamwhite ?