[buddypress-trac] [BuddyPress Trac] #7401: Wrong user data leak with external object cache

buddypress-trac noreply at wordpress.org
Tue Dec 20 16:21:54 UTC 2016

#7401: Wrong user data leak with external object cache
 Reporter:  m_uysl                 |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  2.8
Component:  Extended Profile       |     Version:  2.0
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
Changes (by boonebgorges):

 * keywords:  has-patch => has-patch 2nd-opinion


 @m_uysl - Thanks a lot for the ticket and the patch! It's helped me to
 understand the issue a bit better. It's now clear to me why the cache
 corruption happens in the case where an admin is editing another user's
 profile. The mechanics of the more general case (as described in #6091)
 are still not clear to me, but I'm fairly sure they're related.

 It seems to me that the underlying architectural problem here is that
 cached data for another user is fetched in the first place. When you call
 `BP_XProfile_Group::get()`, the field objects are populated using
 `xprofile_get_field()`. This instantiates a `BP_XProfile_Field` object,
 with the default `$user_id` and `$get_data` params. As such, these field
 objects contain data for the *logged-in* user, even if you are fetching
 the fields/groups of another user.

 There are a bunch of ways to address this. The one that requires the least
 amount of code is [attachment:7401.2.diff]. Briefly: when fetching the
 field objects in `BP_XProfile_Group::get()`, be sure to request them in a
 way that doesn't fetch any user data at all. (`BP_XProfile_Group::get()`
 gets the needed user data separately.) This change requires passing around
 the `$user_id` and `$get_data` params, which I don't really like, but it
 does the trick.

 @m_uysl and @r-a-y What do you think of this more general change? As far
 as I can see, it will ensure that this kind of cross-pollination is
 impossible in the future.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7401#comment:2>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list