Changes between Initial Version and Version 1 of Ticket #43392, comment 7
- Timestamp:
- 08/09/2018 10:47:40 PM (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #43392, comment 7
initial v1 5 5 Input from the API client needs to always be a JSON array, which is easily converted into a PHP array, and then can be stored easily via serialization. We never, ever accept a string that represents a serialized thing, which could be a serialized PHP class, which expands the attack vector like @rmccue was talking about in his blog post. So, this way we're never unserializing user input. 6 6 7 Those same fields only ever serve PHP array which map nicely into JSON objects. So this way it's not lossy either, which was @rmccue's other main problem.7 Those same fields only ever serve PHP array which map nicely into JSON objects. So this way it's not lossy either, which was @rmccue's other main hold-up. 8 8 9 9 So I don't see why WP core couldn't likewise support `register_meta()` with `'type' => 'array'`, where the input is always JSON arrays (which is received as a PHP array and gets serialized, so it wouldn't actually need to run `maybe_serialize()`), and the value is stored in the DB as a serialized array, and then when retrieving the data from the DB, we unserialize it to a PHP array, and then serve it as a JSON object again over the REST API. (Optionally, WP core could decide on a different method of serializing the PHP array, like `json_encode`ing, but continuing with PHP's `serialize` methods is more consistent).