Context Navigation

Changes between Initial Version and Version 1 of Ticket #61837, comment 4

initial	v1
3	3	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.
4	4
5		That said, I agree that a 500 due to a bad type internally is ~~the correct response her~~e! Thanks for the report.
	5	That said, I agree that a 500 due to a bad type internally is NOT the correct response! Thanks for the report.
6	6
7	7	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?