Ticket #2977 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

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

Reported by: hgfischer Assigned to: 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 (0.8 kB) - added by mdawaffe on 07/27/06 05:38:29.
WP interface with old version of sack seems to require double (en|de)coding

Change History

07/26/06 13:52:49 changed by hgfischer

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;

07/27/06 05:37:22 changed by mdawaffe

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

07/27/06 05:38:29 changed by mdawaffe

  • attachment 2977.diff added.

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

07/27/06 05:39:45 changed by mdawaffe

  • keywords set to has-patch commit.

07/27/06 07:11:47 changed by ryan

  • status changed from new to closed.
  • resolution set to fixed.

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

11/30/06 19:41:50 changed by

  • milestone deleted.

Milestone 2.0.4 deleted