[wp-trac] [WordPress Trac] #26855: get_blogaddress_by_id used in wp-activate.php limits functionality in MU Domain Mapped Sites

[WordPress Trac]

#26855: get_blogaddress_by_id used in wp-activate.php limits functionality in MU
Domain Mapped Sites
-----------------------------------+------------------------------
 Reporter:  boboudreau             |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Networks and Sites     |     Version:  3.0
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:  multisite
-----------------------------------+------------------------------

Comment (by boboudreau):

 I'd like to bump this ticket and patch request again.  I just ran into a
 **different** issue that would be solved by using `get_site_url` again
 instead of `get_blogaddress_by_id`.

 Many websites use plugins to mask the location of the sign-in URL or to
 change it completely so that they aren't slammed with bots trying to POST
 data to wp-login.php all the time.  Here, the welcome page after
 successfully activating a new user is FORCED to be http://example.com/wp-
 login.php.

 If you have an aggressive strategy for keeping out undesirable users, you
 won't accept someone browsing to wp-login.php and then taking them to the
 right place where they can login.  You only want to accept login attempts
 from the URL where you've directed your users, and you don't want  bots to
 be able to follow links to find the login page you're trying to hide to
 begin with.

 However, you cannot change the behavior of generating the login link other
 than by hacking core, because get_blogaddress_by_id does not offer any
 filters, and in conjunction with the lines

 {{{
 $url = isset( $result['blog_id'] ) ? get_blogaddress_by_id( (int)
 $result['blog_id'] ) : '';
 }}}

 and

 {{{
 <p class="view"><?php printf( __('Your account is now activated. <a
 href="%1$s">View your site</a> or <a href="%2$s">Log in</a>'), $url, $url
 . 'wp-login.php' ); ?></p>
 }}}

 and even more specifically with the code `$url . 'wp-login.php'`, we're
 basically hard-coding `wp-login.php` in the output.

 Giving users flexibility to modify the site URL was the whole reason why
 the `site_url` filter exists, right? So why limit that flexibility by not
 allowing it here?

 As my current project has grown we've had numerous problems with users not
 being able to get to where we want them to go, mostly because WordPress
 doesn't have a clean way to handle filtering the URLs if we want some
 obscurity behind the standard `wp-login` & `wp-admin` paths.  I'm hoping I
 don't have to hack core - this is becoming one of our more important bugs
 to fix, as we're in the "busy season", and our number of editors and
 authors is growing at about ~100 users a day (and many of them not all
 that tech-savvy).

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