[wp-trac] [WordPress Trac] #61837: REST API: Uncaught TypeError when post password is provided as integer (was: Uncaught TypeError in wp/v2/posts/{id} endpoint)

[WordPress Trac]

#61837: REST API: Uncaught TypeError when post password is provided as integer
--------------------------+------------------------------
 Reporter:  mlf20         |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:  6.2.2
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  rest-api
--------------------------+------------------------------

Comment (by kadamwhite):

 The issue being reported is that an error is thrown when a numeric
 password is provided as an integer instead of as a string, correct?

 The schema for the password property of a Post object specifies it is
 expected to be provided a `string`, not an integer: see
 [https://github.com/WordPress/wordpress-
 develop/blob/ca64c851f7d73a48fa19a5d54467d45fc66a1098/src/wp-includes
 /rest-api/endpoints/class-wp-rest-posts-controller.php#L2341
 WP_REST_Posts_Controller::get_item_schema]. The column for post password
 itself is a `varchar(255)`, and we use a regular textual input box for the
 password on the WordPress UI and frontend. So there's an argument that an
 integer password ''shouldn't'' be accepted, because you should supply the
 password as a string, the way the schema expects.

 That said, I agree that a 500 due to a bad type internally is the correct
 response here! Thanks for the report.

 The [https://github.com/WordPress/wordpress-develop/pull/7172/files linked
 PR] adds a specific type check within the password validation function.
 Before landing that (or adding a type coercion to ensure the value is a
 `string` before passing to `hash_equals()`, so that we don't error out
 early without a good message), we should check whether there is a missing
 layer of existing validation -- is this hash check running ''before''
 schema validation, or is schema validation not kicking in at all when a
 non-string is provided?

 I'd personally prefer we unify this check with the other schema
 validation, rather than introducing a one-off check into this function.

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