[wp-trac] [WordPress Trac] #14046: WP_User constructor not working as expected if called with 2 args

WordPress Trac wp-trac at lists.automattic.com
Fri Jun 25 11:45:32 UTC 2010


#14046: WP_User constructor not working as expected if called with 2 args
-----------------------------+----------------------------------------------
 Reporter:  francescolaffi   |       Owner:                  
     Type:  defect (bug)     |      Status:  new             
 Priority:  high             |   Milestone:  3.0.1           
Component:  Role/Capability  |     Version:  3.0             
 Severity:  critical         |    Keywords:  has-patch commit
-----------------------------+----------------------------------------------

Comment(by francescolaffi):

 Replying to [comment:9 nacin]:
 > We need to fix is_site_admin(). is_super_admin('admin') returns true,
 is_site_admin('admin') returns false, that's really bad for MU back
 compat.
 yep and in particular situation it can also do bad jokes, i.e. in an user
 deletion action the is_site_admin check to prevent admins deletion failed,
 so the only admin got deleted, luckily it was only a test install

 > I like adding empty() to WP_User.
 That was my first choice but the problem seems more complicated than that.
 hakre noticed and tried to solve another problem of WP_User:
 what happen if an user has an user_login that is a numeric value and the
 WP_User is called with user_login in the first argoument?

 I'm doing some tests and this could be also a security problem: [[BR]]
 i.e. if someone register with user_name '1', what happens if in a
 particular situation instead of doing
 {{{new WP_User($user_id)}}} I do {{{new WP_User($user_name)}}}?
 if the user has $user_name '1' instead of it I get the user with id 1,
 think what happen if if then I check has_cap on it!! [[BR]]
 with this new fact my opinion is that it should not be possible at all
 calling {{{WP_User($username)}}} but only {{{WP_User($user_id)}}} or
 {{{WP_User(null,$username)}}}

 about is_site_admin.diff : [[BR]]
 I think this should be applied also if problem is solved in WP_User,
 actually is_site_admin doesn't need the whole WP_User because it doesn't
 access to caps, so using get_userdatabylogin means a smaller obj and
 probably one less query

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14046#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list