Ticket #2977 (closed defect (bug): fixed)

Opened 6 years ago

Last modified 5 years ago

Username/Nickname with spaces cannot delete it's own posts or comments

Reported by: hgfischer Owned by: mdawaffe
Priority: high Milestone:
Component: Administration Version: 2.0.3
Severity: major Keywords: has-patch commit
Cc:

Description

When logging in with an username that has space in it (like "foo bar") I cannot delete my own posts or comments. WordPress just shows me that I cannot do this because I have no permission. I created this username with Author roles. When using a username without spaces this problem does not occur.

Attachments

2977.diff Download (804 bytes) - added by mdawaffe 6 years ago.
WP interface with old version of sack seems to require double (en|de)coding

Change History

I found the source of the problem. It's in the WordPress AJAX code. Spaces are encoded as "+" by the browser so WP cannot found "foo+bar" and authenticate them. I don't know if it is some other place to fix this but I solved my problem adding "urldecode" calls to the "wp-includes/pluggable-functions.php" check_ajax_referer function:

if ( !function_exists('check_ajax_referer') ) : function check_ajax_referer() {

$cookie = explode('; ', urldecode(empty($_POSTcookie?) ? $_GETcookie? : $_POSTcookie?)); AJAX scripts must pass cookie=document.cookie foreach ( $cookie as $tasty ) {

if ( false !== strpos($tasty, USER_COOKIE) )

$user = urldecode(substr(strstr($tasty, '='), 1));

if ( false !== strpos($tasty, PASS_COOKIE) )

$pass = urldecode(substr(strstr($tasty, '='), 1));

}

if ( wp_login( $user, $pass, true ) )

return true;

return false;

} endif;

  • Owner changed from anonymous to mdawaffe

hgfischer, nice catch!

This applies to users with username containing any character needing urlencoding: space, @, etc.

Tangentially related to #2969.

The reason we had wp_clean_ajax_input() in trunk to urldecode $_POST was because the old version of sack required it (it may have been double encoding...? I don't recall). With the new version of sack in trunk, wp_clean_ajax_input() was detrimental.

We still have the old version of sack in branches/2.0 (as we should), so we need to decode there.

This should not be an issue elsewhere in the core. I believe branches/2.0 only deals with integers being sent by AJAX requests (except for on the fly category addition which handles things on its own).

Patch looks good. Submitting as diff.

Note: this bug does not apply to trunk; everything is fine there.

WP interface with old version of sack seems to require double (en|de)coding

  • Keywords has-patch commit added

comment:4   ryan6 years ago

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

(In [4053]) Sack encoding fix from hgfischer. fixes #2977

  • Milestone 2.0.4 deleted

Milestone 2.0.4 deleted

Note: See TracTickets for help on using tickets.