Make WordPress Core

Opened 11 years ago

Closed 10 years ago

#25311 closed task (blessed) (fixed)

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

Reported by: scribu's profile scribu Owned by:
Milestone: 3.7 Priority: normal
Severity: normal Version:
Component: WordPress.org Site Keywords: needs-docs
Focuses: Cc:

Description (last modified by 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

Attachments (1)

25311.diff (4.0 KB) - added by nacin 11 years ago.

Download all attachments as: .zip

Change History (18)

#1 @scribu
11 years ago

  • Description modified (diff)

#2 @scribu
11 years ago

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.

#3 @nacin
11 years ago

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.

#4 @scribu
11 years ago

Good to hear.

RE testing environment: #meta191.

@nacin
11 years ago

#5 follow-up: @nacin
11 years ago

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.

#6 in reply to: ↑ 5 ; follow-up: @dd32
11 years ago

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."

#7 in reply to: ↑ 6 @nacin
11 years ago

Replying to dd32:

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

Ah, I completely forgot about that.

#8 @nacin
11 years ago

In 25441:

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

#9 @nacin
11 years ago

In 25442:

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

#10 @nacin
11 years ago

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().

#11 @SergeyBiryukov
11 years ago

  • Milestone changed from Awaiting Review to 3.7

#12 follow-up: @nacin
11 years ago

In 25514:

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

#13 in reply to: ↑ 12 @nacin
11 years ago

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.

#14 @nacin
10 years ago

  • Type changed from enhancement to task (blessed)

#15 @johnbillion
10 years ago

  • Keywords needs-docs added

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.

#16 @meloniq
10 years ago

  • Cc meloniq@… added

#17 @nacin
10 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.