[wp-trac] [WordPress Trac] #42610: Admin created account password reset process not reverse proxy friendly

[WordPress Trac]

#42610: Admin created account password reset process not reverse proxy friendly
------------------------------------+-----------------------------
 Reporter:  normjhansen             |      Owner:
     Type:  defect (bug)            |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Login and Registration  |    Version:  4.9
 Severity:  normal                  |   Keywords:
  Focuses:                          |
------------------------------------+-----------------------------
 WordPress newbie, so feel free to point me to a better resolution.
 Couldn't find anything quite like this.

 Have WP running mostly correctly behind a reverse proxy. So no one ever
 directly touches blog.<domain>.com (the WP site), instead they access it
 through www.<domain>.com/blog

 If I create user accounts in the admin, it sends initial password reset
 links to the new accounts, which have a format like www.<domain>.com/blog
 /wp-login.php?action=rp&key=<hash>&login=<user>

 In wp-login.php, I see the case that catches the rp action, and it does
 something with the key and user parameters, then strips them off and
 redirects again to wp-login as follows:

 {{{#!php
 wp_safe_redirect( remove_query_arg( array( 'key', 'login' ) ) );
 }}}

 I'm unclear on why this line doesn't incorporate site_url as do several
 other places in nearby code. The user ends up getting a redirect to /wp-
 login.php. That is, from the '''user's perspective''' (not seeing the
 reverse proxy activity), it looks like:

 www.<domain>.com/blog/wp-login.php?action=rp&key=<hash>&login=<user>
 redirects to
 www.<domain>.com/wp-login.php?action=rp
 which is a 404

 From the '''WP server's''' perspective, it told
 blog.<domain>.com/wp-login.php?action=rp&key=<hash>&login=<user>
 to redirect to
 /wp-login.php?action=rp
 which would have been fine if there were no reverse proxy involved.

 This is not the desired behavior in my case, and I would think it would be
 safe to redirect to
 <site_url>/wp-login.php?<query string with key and login removed>

 I can work around it in the main site's rewrite rules by forcing /wp-login
 to /blog/wp-login, but that seems as if it shouldn't be necessary.

 Thanks for your consideration.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42610>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform