REST API pagination: Large INT passed to `paged` query arg doesn't fail properly

[morganestes]

When an absurdly large value is passed to the REST API (e.g. /wp/v2/pages?page=23924321212413345333), it returns the first page of results instead of an error. The problem is during validation and sanitization of the value, where the passed value is run through absint, which returns another absurdly large value, which then gets nullified by PHP, which becomes 1.

wp> print_r( rest_sanitize_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) );
3481259413623275520
=> bool(true)
wp> print_r( rest_validate_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) );
1
=> bool(true)

wp> absint(23924321212413345333);
=> int(5477577138703794176)

Edge case, but worth noting since smaller values that are larger than the number of pages return an empty array (like if there are only 2 pages of posts, but 3 are requested).

Related: #19728.

[rachelbaker]

Related #28559

@morganestes want to work on a patch?

[morganestes]

@rachelbaker yep, I'll work on "smaller values that are larger than the number of pages return an empty array (like if there are only 2 pages of posts, but 3 are requested)."

[morganestes]

39061.diff​ is a first pass at returning an error for an out-of-bounds page request for posts. If this looks right, I'll do the same for the other endpoints.

[morganestes]

Added a test for OOB posts pagination in 39061.2.diff​.

[morganestes]

In 39061.3.diff​: make sure to check for no posts in a response before returning an error. This prevents unintended failure on empty arrays when none are expected.

[rmccue]

It seems like the cutoff value here is PHP_INT_MAX, so could we just check $value > PHP_INT_MAX?

[joehoyle]

In 39967:

REST API: Return an error if the page number is out of bounds.

Return an error from the REST API if a page number larger than the total pages count is requested.

Props morganestes.
Fixes #39061.

[joehoyle]

In 39991:

REST API: Fix unit tests for posts out of bounds errors

Previously we were assuming pagination headers would be sent when the request for posts is out of bounds. Instead presume it will return an error.

See #39061.

[ocean90]

We should do the same for all endpoints (terms, comments and users) as mentioned in comment:3.

[joehoyle]

Attached a patch for comments endpoint with the same functionality:

1. Handle page query var that is bigger than PHP_MAX_INT.
2. Show an out of bounds error if the page is larger than X-TotalPages

Like /wp/v2/posts we also no longer return pagination headers in the case of the out of bounds error.

[jbpaul17]

Punting to 4.8.1 per today's bug scrub.

[jbpaul17]

Punting to 4.9 per today's bug scrub and so @morganestes can split out tickets for all endpoints (terms, comments and users).

[jbpaul17]

Punting this to Future Release per the 4.9 bug scrub earlier today.