Lack of unslashing in privileged handler of the Heartbeat API

[TobiasBg]

The handler for not-logged-in ("nopriv") calls to the Heartbeat API (see #23216), wp_ajax_nopriv_heartbeat(), (incorrectly) unslashes the $_POST['data'] array, while wp_ajax_heartbeat() (correctly) does not.
wp_unslash() is not necessary in both cases, as unslashing has already been done globally via wp_magic_quotes() by the time the filters run.

This was introduced by an unfortunate timing of commits/reverts:

• [23355] introduced the (logged-in) Heartbeat API handler, without unslashing.
• [23416] added the unslashing in an attempt (see #21767) to handle the overall slashing mess in core.
• [23481] added the "nopriv" Heartbeat API handler, with unslashing (because of #21767/[23416]).
• [23554] reverted [23416] but did not catch the wp_unslash() that had been added in [23481] in the mean time.

The attached patch removes the extra wp_unslash() call.

[TobiasBg]

Remove wrong wp_unslash()

[johnbillion]

What an incredible mess this is. We've somehow managed to introduce brand new functionality in the form of the heartbeat API which relies on slashed data.

Replying to TobiasBg:

wp_unslash() is not necessary in both cases, as unslashing has already been done globally via wp_magic_quotes() by the time the filters run.

Although wp_unslash() is indeed not needed here, that's not the reason. wp_magic_quotes() adds slashes globally, it doesn't remove them. The problem is that the callback functions hooked into the heartbeat API expect slashed data (the main culprit being edit_post() in wp_autosave() which is called by heartbeat_autosave().

TL;DR the patch is correct, the reason for it isn't.

[nacin]

In an ideal world, we should immediately unslash $_POST references with wp_unslash(), and then re-slash it with wp_slash() immediately before passing it to an API that expects slashed data. The API itself should not be reliant on slashed data.

[johnbillion]

27260.patch​ changes the Heartbeat API so it uses unslashed data instead. The data should be slashed JIT before it goes into any API function that does expect slashed data.

Of the four actions hooked into heartbeat_received in core, only heartbeat_autosave() ultimately needs to deal with slashes. It calls wp_autosave() which calls edit_post() and wp_create_post_autosave(), both of which expect slashed data.

I think this is the preferable solution, otherwise we'll be stuck with an otherwise wonderful Heartbeat API that uses slashed data.

[TobiasBg]

Argh, why do I always have wp_magic_quotes() backwards in my head? Wishful thinking? Are slashes slashing my brain? (Bad puns are on me.)

My patch doesn't make sense then, of course, as filters hooking into heartbeat_received would have to do the unslashing themselves.

johnbillion's patch looks sane.

[nacin]

In 27576:

Heartbeat: Hooks should always receive unslashed data.

This affects the privileged hooks; the unprivileged hooks already received unslashed data.

props johnbillion, TobiasBg.
fixes #27260.