[wp-trac] [WordPress Trac] #38583: Support for objects in schema validation and sanitization

[WordPress Trac]

#38583: Support for objects in schema validation and sanitization
----------------------------------------+-----------------------
 Reporter:  rachelbaker                 |       Owner:  rmccue
     Type:  enhancement                 |      Status:  reopened
 Priority:  high                        |   Milestone:  4.9
Component:  REST API                    |     Version:  4.7
 Severity:  major                       |  Resolution:
 Keywords:  has-unit-tests needs-patch  |     Focuses:
----------------------------------------+-----------------------

Comment (by joehoyle):

 I've pinged @rmccue for his thoughts here too.

 I'm strongly against supporting `additionalProperties` if it means "store
 any extra data that's in the object even if it doesn't have a registered
 schema". We are only able to accept the data we do because of type
 information we get via the registered schema. Without this, we won't be
 able to cast types, and is also a forwards compatibility problem.

 This patch is / was to _start_ supporting `object` so we can at-least now
 build up complex registered structures by combining `array`, `object`,
 `integer`, `number`, `string` and `boolean`. I don't see a case where we
 _would_ wholesale accept objects with properties of unknown data types and
 insert them into the database.

 I agree we do need to fix the case outlined by @mnelson4 I just don't
 think this needs to mean allowing unregistered properties to get saved.

 > I appreciate @joehoyle is trying to not add anything unnecessary on this
 commit. But if additionalProperties is not supported now, and non-
 whitelised properties are removed, then IMO...

 In this case we could just set `additionalProperties: false` to be spec-
 compliant.

 @mnelson4 and @TimothyBlynJacobs:

 I'm not 100% sure if you are just wanting an object to be validated by the
 schema, and respect `additionalProperties`, or are you _also_ wanting to
 use `register_meta` / `register_rest_field` et al to actually support that
 from an API client, whereby the server should accept the additional data,
 store it, and return it on fetching that object?


 I can see how we could not strip additional properties in sanitization,
 _maybe_, but we'd just move the property whitelisting to the Meta /
 Settings / REST Field level, to have _those_ features not support
 `additionalProperties`.

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