[wpmu-trac] [WordPress MU Trac] #1076: Infinite Loop on New User Login

[WordPress MU Trac]

#1076: Infinite Loop on New User Login
----------------------------+-----------------------------------------------
 Reporter:  deannas         |       Owner:  somebody 
     Type:  enhancement     |      Status:  new      
 Priority:  normal          |   Milestone:           
Component:  Administration  |     Version:  2.8.2    
 Severity:  normal          |    Keywords:  has-patch
----------------------------+-----------------------------------------------
Changes (by jamescollins):

  * keywords:  => has-patch


Comment:

 I have debugged this some more.

 Replying to [ticket:1076 deannas]:
 > An infinite loop occurs when you perform the following:[[BR]]
 >
 > 1. Log in as site admin and create a new user.[[BR]]
 > 2. Create a new blog and make the new user the blog admin.[[BR]]
 > 3. Log in as new user.[[BR]]

 The problem is caused only when following the above instructions exactly.

 The procedure is as follows:

 When the user account is created (via site admin -> users), their
 primary_blog is set to 1 (the main blog). They are also given a subscriber
 role on the main blog.

 Then, going to site admin -> blogs, and using the add blog form (with the
 new user's email address), the new blog is created for them, and they are
 given an administrator role on the new blog, but also their subscriber
 role on the main blog is removed and their primary_blog record still
 points to blog id 1.

 So when they try and log in to the main blog, they don't have any
 permissions on the main blog, but their primary_blog record is still
 pointing to the main blog.

 This causes the redirect loop, and eventually (thanks to Donncha's
 change), to display a message of:

 "You don’t have permission to view this blog. Please contact the system
 administrator."

 The WPMU code is actually supposed to update the primary_blog option to
 the newly created blog, but due to a bug in the code this doesn't occur.

 I have attached a patch that fixes the underlying problem.

 This won't fix the existing user accounts that may be broken (which have a
 wp_usermeta record of primary_blog = 1 and no wp_1_capabilities usermeta
 record).

 We could write an upgrade task that did a get_blogs_of_user() on each user
 account, and if the function only returns one blog, then update their
 primary_blog option to the blog id of the single blog.

 I'm not sure of the best place to do this though.

-- 
Ticket URL: <http://trac.mu.wordpress.org/ticket/1076#comment:5>
WordPress MU Trac <http://mu.wordpress.org/>
WordPress Multiuser