Replace PHP-serialized data with JSON in api.wordpress.org

[scribu]

Returning PHP-serialized strings in api.wordpress.org is lame, for two reasons:

Security

It has the potential to lead to security exploits via PHP object injection: ​http://vagosec.org/2013/09/wordpress-php-object-injection/

Considering that Core doesn't use HTTPS for most requests it makes to api.wordpress.org, this is even more plausible.

Portability

It's hard to unserialize these strings in other languages besides PHP. JSON is the obvious replacement.

Related: ​#meta124

[scribu]

I would volunteer to work on this, but from the discussions at WPCS, it's tricky to get access to the code that's powering api.wordpress.org, not to mention a testing environment for it.

[nacin]

Mostly handled by #18577 (moving to https for api.wordpress.org) and [25219] (core/version-check/1.7 is now JSON).

There are some other endpoints that still used serialized strings; I'm fine with moving away from those.

[scribu]

Good to hear.

RE testing environment: ​#meta191.

[nacin]

25311.diff​ receives JSON-encoded data from 1.1 endpoints for core/browse-happy, importers, and credits. It's the same data structures as the serialized data, which means associative arrays become objects. Here, I've chosen to manually convert them back to arrays for storage and reference.

Two of them (browse-happy, importers) are simple, and also correspond to the array-based return of public functions. Credits is a bit more complicated of a data structure; and we could very likely get away with changing the return value of wp_credits() (and also the data type of the transient) and then change all of the references from arrays to objects.

[dd32]

Replying to nacin:

which means associative arrays become objects. Here, I've chosen to manually convert them back to arrays for storage and reference.

The 2nd parameter of json_decode() can be used to convert them to arrays, which is what [25219] did "When TRUE, returned objects will be converted into associative arrays."

[nacin]

Replying to dd32:

The 2nd parameter of json_decode() can be used to convert them to arrays

Ah, I completely forgot about that.

[nacin]

In 25441:

Move to JSON for three api.wordpress.org endpoints. see #25311.

[nacin]

In 25442:

Move to JSON for the plugin and theme update-check API endpoints. see #25311.

[nacin]

We need to carefully look through the return values of the theme and plugin API /info/ endpoints as they have quite a bit of variance in return values. Need to not break existing usage of plugins_api() and themes_api().

[nacin]

In 25514:

Further adjust the request and response formats for plugin and theme update checks. see #25311.

[nacin]

Replying to nacin:

In 25514:

Further adjust the request and response formats for plugin and theme update checks. see #25311.

This breaks update checks in the latest nightly build, so I've regenerated it.

[johnbillion]

We'll need a blog post on Make/Core about this change due to the following.

Plugins that hook into the http_request_args filter in order to filter out plugins or themes from the api.wordpress.org update checks will break update checks entirely due to expecting serialised data and instead getting JSON encoded data.

I've ​updated a plugin of mine so it supports JSON encoded data and serialised data, but I only did this after getting PHP warnings and noticing that updates were broken.

[nacin]

Closing this as fixed; we'll handle the blog post on make/core and also the /info/ endpoints in 3.8.