Context Navigation

← Previous Ticket
Next Ticket →

#65594 closed defect (bug) (fixed)

Abilities API: REST run requests pass untyped input to ability callbacks

Reported by:	jorgefilipecosta	Owned by:	jorgefilipecosta
Priority:	normal	Milestone:	7.1
Component:	Abilities API	Version:
Severity:	normal	Keywords:	has-patch has-unit-tests commit
Cc:		Focuses:

Description

The Abilities API run endpoint (WP_REST_Abilities_V1_Run_Controller) hands an ability's
permission_callback and execute_callback the input exactly as it came off the request,
without coercing it to the types declared in the ability's input_schema.

Over GET and DELETE, PHP delivers every scalar in the query string as a string, and a
comma-separated list as a single string. WP_Ability::validate_input() is lenient enough to
accept "10" where the schema declares integer, but validation does not mutate the
value, so the callback still receives "10" and not 10.

Steps to reproduce

<?php
'input_schema' => array(
        'type'       => 'object',
        'properties' => array(
                'count' => array( 'type' => 'integer' ),
                'flag'  => array( 'type' => 'boolean' ),
                'tags'  => array(
                        'type'  => 'array',
                        'items' => array( 'type' => 'string' ),
                ),
        ),
),

Request it over GET:

/wp-json/wp-abilities/v1/abilities/test/typed-input/run?input[count]=10&input[flag]=true&input[tags]=a,b

Inspect the $input the execute_callback receives.

Expected: 10 (integer), true (boolean), array( 'a', 'b' ) (array).
Actual: "10", "true", "a,b" — all strings.

Consequences

Strict comparisons in ability callbacks silently fail: true === $input['flag'] is never true when the value arrives as "true".
Behavior depends on transport. The same ability invoked over POST (JSON body, native types) and over GET (query string, strings) receives different PHP types for the same logical input.
Every read ability has to hand-roll coercion — (int), wp_parse_list(), 'true' === $value

Proposed fix

Coerce the extracted input against the ability's registered input schema at the run controller
boundary, before validation and execution, on both the permission and the execution path.

Coercion belongs in the controller rather than in WP_Ability: it is a REST-transport artifact,
and direct PHP callers already pass typed values. Sanitizing against get_input_schema() — the
same registered snapshot validate_input() runs against — keeps coercion and validation in
agreement.

Coercion must be non-destructive with respect to validation:

Only coerce input that already validates. Sanitizing invalid input would otherwise rescue it: additionalProperties: false errors in rest_validate_value_from_schema() but only strips in rest_sanitize_value_from_schema(), and a non-numeric string casts to 0.
If sanitizing still surfaces an error the lenient validation did not — for example ["1", "01"] under uniqueItems with items: integer, unique as strings but colliding once cast — including an error nested inside the returned array, fall back to the raw input unchanged.

validate_input() therefore remains the single authority on what is accepted, and still emits the
user-facing ability_invalid_input (400). null input and abilities without an input schema pass
through untouched.

Values injected by a wp_ability_normalize_input filter run after this coercion and are not
coerced. Centralizing that in WP_Ability::normalize_input() would also change behavior for direct
PHP callers, so it is left out of scope.

Follow-up

Once this lands, the per-ability coercion in core/read-users and core/read-content (AI plugin, and core PR's) can be removed and their coercion tests re-pointed at the controller.

PR: https://github.com/WordPress/wordpress-develop/pull/12437

Change History (3)

This ticket was mentioned in PR #12437 on WordPress/wordpress-develop by @jorgefilipecosta.

2 days ago #1

Keywords has-unit-tests added

## What

Coerce the input of an Abilities REST _run_ request to the types declared in the ability's input_schema before the ability runs, so permission_callback and execute_callback receive natively typed input (10 not "10", true not "true", ["a","b"] not "a,b") regardless of transport.

## Why

Over GET/DELETE, PHP delivers every scalar in the query string as a string, and a comma-separated list as a single string. WP_Ability::validate_input() is lenient enough to _accept_ "10" as an integer but does not mutate it, so the ability callback received raw strings. Strict checks such as true === $input['flag'] silently failed, and every read ability had to hand-roll its own coercion ((int), wp_parse_list(), 'true'→bool). This centralizes that at the REST boundary.

## Approach

Coercion runs in WP_REST_Abilities_V1_Run_Controller — a REST-transport artifact, so it stays out of the transport-agnostic WP_Ability (direct PHP callers already pass typed values). It sanitizes against get_input_schema(), the same registered snapshot validate_input() uses, so coercion and validation always agree. It is applied on both the permission and execution paths through the shared get_input_from_request(), which now optionally receives the resolved ability.

Coercion is non-destructive with respect to validation:

Input is coerced only when it already validates against the schema. This prevents sanitizing from _rescuing_ otherwise-invalid input: additionalProperties: false would otherwise silently strip unknown keys (it errors in rest_validate_value_from_schema() but only strips in rest_sanitize_value_from_schema()), and a non-numeric string would cast to 0.
If sanitizing still surfaces an error — e.g. items that are unique as strings but collide once cast to integers under uniqueItems — including one nested inside the returned array, the raw input is returned unchanged.

validate_input() therefore remains the single authority on what is accepted and still emits the user-facing ability_invalid_input error. null input and abilities without an input schema pass through untouched.

Values _injected_ by a wp_ability_normalize_input filter run after this coercion and are not coerced; a future framework-level centralization in WP_Ability::normalize_input() could cover that, at the cost of changing behavior for direct PHP callers.

## Testing instructions

npm run test:php -- --group abilities-api

New cases in tests/phpunit/tests/rest-api/wpRestAbilitiesV1RunController.php cover:

GET scalar→int/bool and comma-separated→array coercion
oneOf branch resolution with per-branch coercion (id mode vs collection mode)
invalid input still returning 400 ability_invalid_input (unknown property under additionalProperties: false, and a non-numeric integer)
already-typed POST input left unchanged
ability without an input schema passing through
the nested-uniqueItems fall-back to raw input

Reverting only the controller change makes the two coercion assertions fail (string vs integer), demonstrating the fix.

## Follow-up (separate PR)

Once this lands, the per-ability coercion in core/read-users and core/read-content can be simplified/removed and their coercion tests re-pointed at the controller.

#2 @gziolo
45 hours ago

Keywords commit added
Owner set to jorgefilipecosta
Status new → assigned

#3 @jorgefilipecosta
29 hours ago

Resolution → fixed
Status assigned → closed

In 62674:

Abilities API: Coerce REST run input to the ability input schema.

REST GET and DELETE requests deliver every query string parameter as a string ("10", "true") and comma-separated values as a single string, so without coercion an ability receives raw strings where its input schema declares integers, booleans, or arrays.
This commit coerces the run input to the types declared by the ability's input schema before the ability executes. The coercion is registered as the input argument's sanitize_callback, so it runs once during sanitize_params() and both the permission and execution callbacks receive natively typed input from the same request object.

Props jorgefilipecosta, gziolo, mukesh27.
Fixes #65594.

Note: See TracTickets for help on using tickets.

Download in other formats:

Make WordPress Core