[wp-trac] [WordPress Trac] #41834: wp_redirect issue with HTTPS and when $redirect_to is more than one directory deep

WordPress Trac noreply at wordpress.org
Fri Sep 8 13:49:30 UTC 2017


#41834: wp_redirect issue with HTTPS and when $redirect_to is more than one
directory deep
-------------------------------------------------+-------------------------
 Reporter:  joneslloyd                           |      Owner:
     Type:  defect (bug)                         |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
Component:  General                              |  Review
 Severity:  normal                               |    Version:  4.8.1
  Focuses:  administration, template,            |   Keywords:
  performance                                    |
-------------------------------------------------+-------------------------
 Below is a simplified version of my code, which produces the error:

 {{{#!php
 <?php
 /**
  * Redirect users after login
  */
 add_filter('login_redirect', function ($redirect_to, $request, $user) {
     if (isset($user->roles) && is_array($user->roles)) {
         if (! empty($redirect_to)) {
             wp_redirect($redirect_to);
         } elseif (in_array('administrator', $user->roles)) {
             wp_redirect(admin_url());
         } else {
 wp_redirect(get_the_permalink(get_default_page_id('dashboard')));
         }

         exit;
     }
 }, 10, 3);
 }}}


 As per the code above, if `$redirect_to` is not empty, users are
 redirected to that URL.

 I've found that when running a site on HTTPS, an issue arises when
 `$redirect_to`'s value contains more than one directory / level.

 For example, when I want to redirect to `https://mysite.com/dashboard/`,
 the redirect occurs correctly (and the value of `$redirect_to` is
 `https://mysite.com/dashboard/`, as expected).

 However, when I try to redirect to `https://mysite.com/modules/module-0/`,
 the value of `$redirect_to` is actually
 `https:/mysite.com/modules/module-0/` -- Notice the second `/` after the
 colon is removed.

 This (I believe) then causes WordPress to strip out the broken `https:/`
 when `wp_sanitize_redirect` is called inside of the `wp_redirect`
 function, and the resultant redirect that actually occurs in the web
 browser is `https://mysite.com/mysite.com/modules/module-0/` (which is a
 404 error).

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


More information about the wp-trac mailing list