[wp-trac] [WordPress Trac] #28435: wp_update_user breaks when passed WP_User instance (was: wp_insert_user/wp_update_user break when passed WP_User instance)

WordPress Trac noreply at wordpress.org
Tue Jun 3 04:58:45 UTC 2014


#28435: wp_update_user breaks when passed WP_User instance
--------------------------+------------------------------
 Reporter:  rmccue        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Users         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by rmccue:

Old description:

> Supposedly fixed in #21429. (Tangential to #28019)
>
> If you pass a `WP_User` instance to `wp_update_user` or `wp_insert_user`,
> it first calls `WP_User::to_array`, which returns the user data from the
> DB. This is then treated as the input data.
>
> The problem then is that `$userdata['user_pass']` is '''always''' set, as
> it's always included in `$userdata`. This then gets double-hashed by
> `wp_update_user`. (`wp_update_user` will then update the cookies, so the
> user won't notice until they're logged out)
>
> To reproduce:
> {{{
> <?php
> $testuserid = 1;
>
> $user = get_userdata( $testuserid );
>
> echo 'Before: ' . $user->user_pass;
>
> wp_update_user( $user );
>
> // Reload the data
> $user = get_userdata( $testuserid );
>
> echo 'After: ' . $user->user_pass;
> }}}
>
> Current output:
> {{{
> Before: $P$BDqB8PmujqwtUNqnDW/aiQKuAEvm741
> After: $P$BsqV0Lkka4QIWE9RaveZ49wvOMnHD//
> }}}
>
> This operation should have been a no-op, but isn't.

New description:

 Supposedly fixed in #21429. (Tangential to #28019)

 If you pass a `WP_User` instance to `wp_update_user`, it first calls
 `WP_User::to_array`, which returns the user data from the DB. This is then
 treated as the input data.

 The problem then is that `$userdata['user_pass']` is '''always''' set, as
 it's always included in `$userdata`. This then gets double-hashed by
 `wp_update_user`. (`wp_update_user` will then update the cookies, so the
 user won't notice until they're logged out)

 To reproduce:
 {{{
 <?php
 $testuserid = 1;

 $user = get_userdata( $testuserid );

 echo 'Before: ' . $user->user_pass;

 wp_update_user( $user );

 // Reload the data
 $user = get_userdata( $testuserid );

 echo 'After: ' . $user->user_pass;
 }}}

 Current output:
 {{{
 Before: $P$BDqB8PmujqwtUNqnDW/aiQKuAEvm741
 After: $P$BsqV0Lkka4QIWE9RaveZ49wvOMnHD//
 }}}

 This operation should have been a no-op, but isn't.

 (Ticket previously stated this happens with `wp_insert_user`; this is
 incorrect, as `wp_insert_user` doesn't hash the password for updates.)

--

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28435#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list