WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 10 months ago

#16858 reviewing defect (bug)

Usage of HTTP_HOST in the administration

Reported by: amirhabibi Owned by: dd32
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.1
Component: Administration Keywords: has-patch reporter-feedback
Focuses: Cc:

Description

In some files like wp-admin/includes/class-wp-list-table.php (there are more files I think), some links are created by using the HTTP_HOST variable.

It's better to use the defined wordpress URL to create those links.

In our case, we have a wordpress running behind a Squid cache. When you check for HTTP_HOST you get the *real* HOST and not the one with the Squid server.

To bypass the problem, I added in the main config.php a line like this :

$_SERVER['HTTP_HOST'] = 'www.my-visible-http-host.com';

Without this setting and in our case, some links in the admin (next, previous page, re-ordering...) where pointing to the wrong server.

Attachments (2)

16858.patch (1.8 KB) - added by hakre 4 years ago.
Updated patch (missed one)
16858.diff (1.1 KB) - added by dd32 4 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 @hakre4 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

Thanks for reporting the issue.

FWIK the problem you've reported is already known but we were not able to fix this for all installations.

There is however more information in Ticket #9235 that contains some suggestions and code snippets as well to deal with a setup similar to yours.

I therefore close this ticket for now as the solution you put into your issue description is the same suggestion as given in #9235.

comment:2 @dd324 years ago

  • Keywords needs-patch added
  • Resolution duplicate deleted
  • Status changed from closed to reopened

#9235 deals with the IP of the user accessing the site being "wrong" behind a load balancer. This here is a URL being crafted ignoring the rest of the WordPress API (ie. site_url() and friends)

class-wp-list-table.php should really be doing something like $current_url = self_admin_url($_SERVER['REQUEST_URI']); - that however will not work verbatim, as REQUEST_URI will include /wp-admin/ and the list tables may be used in multiple environments..

comment:3 @hakre4 years ago

Yes a function is missing inside core that is able to retrieve the current admin page from request that can be used with the $path parameter of self_admin_url().

self_admin_path() ?

If I read #9235 right, then a function that builds anything close to the return value of get_site_url() or get_admin_url() so to be compared against anything and re-use the remainder as $path does not exists and is highly likely not to be written in the future.

However I don't want to suggest to close this ticket as wontfix. Any idea how this could be solved?

comment:4 @hakre4 years ago

  • Keywords has-patch reporter-feedback added; needs-patch removed

I've attached a patch that did work on my testbed. It makes use of self_admin_url() and an additional function I named self_admin_path() which returns the $path component based on the current request.

@amirhabibi - please apply that patch on your host (the patch is against current trunk) and see if it solves your problem.

@hakre4 years ago

Updated patch (missed one)

comment:6 follow-up: @amirhabibi4 years ago

Very nice work !

The patch seems to solve the problem on our host.

When testing, I saw the same problem somewhere else :

  • the redirection when trying to preview a draft post (the link is good, the redirection not).

Again, by forcing the HTTP_HOST it works.

comment:7 @hakre4 years ago

Replying to amirhabibi:

Very nice work !

The patch seems to solve the problem on our host.

Thanks for the feedback.

When testing, I saw the same problem somewhere else :

  • the redirection when trying to preview a draft post (the link is good, the

redirection not).

I'll take a look if this can be solved with the same approach.

comment:8 in reply to: ↑ 6 @hakre4 years ago

Replying to amirhabibi:

When testing, I saw the same problem somewhere else :

  • the redirection when trying to preview a draft post (the link is good, the redirection not).

I have problems to locate the problem. Can you share the link that "is good"?

comment:9 follow-up: @amirhabibi4 years ago

In fact it's seems more weird.

The "good" link is "http://www.my-visible-http-host.com/?p=164&preview=true". We use permalinks, but in a preview of a draft it's normal.

When we point to that link, we get an infinite loop of 301 redirects (firebug).

I think the problem is somewhere else.

To understand, I tried something like "http://www.my-visible-http-host.com/?p=154" (a normal, visible post). There was a 301 redirect to the pretty permalink structure, then everything ok.

comment:10 in reply to: ↑ 9 ; follow-up: @hakre4 years ago

Replying to amirhabibi:

In fact it's seems more weird.

The "good" link is "http://www.my-visible-http-host.com/?p=164&preview=true". We use permalinks, but in a preview of a draft it's normal.

That's normal, preview links have always this format.

When we point to that link, we get an infinite loop of 301 redirects (firebug).

I think the problem is somewhere else.

I have the feeling that what you describe for the preview redirect is another issue. Please open a new ticket for it and leave the new ticket number here. Looks like something is incompatible on your setup with the wordpress preview feature, probably because of your host configuration.

However, just today I've updated my Better HTTP Redirect Plugin that now contains a debug mode with which you can look what happens behind the scenes in your redirect loop (grab the 1.2.1-beta-1 version).

comment:11 @hakre4 years ago

See wp_requested_url() in ticket:8593:8593.2.patch, might be helpful for such cases esp. if we make it filtereable.

comment:12 follow-up: @dd324 years ago

I don't see a need for these links to be absolute url's, most links in the WordPress admin are relative (ie. just edit.php?..)

We should be able to just call add_query_arg() / remove_query_arg() without the $url parameter first.

However, Looking at the other uses of HTTP_HOST in WordPress, if it's not being corrected afterwards, a lot of login related redirections will fail as well.

@dd324 years ago

comment:13 in reply to: ↑ 12 @hakre4 years ago

Replying to dd32:

I don't see a need for these links to be absolute url's, most links in the WordPress admin are relative (ie. just edit.php?..)

I don't see it either, had running this quite fine: ticket:16932:16932-hotfix-path-mapping.patch

We should be able to just call add_query_arg() / remove_query_arg() without the $url parameter first.

I like the idea and the patch.

However, Looking at the other uses of HTTP_HOST in WordPress, if it's not being corrected afterwards, a lot of login related redirections will fail as well.

They mostly do absolute URIs already as far as I know, the ones which do not, I put on #16909. Absolute URIs normally resolves through the _site_url() which are bound to the setting, not the environment variable and therefore safe.

Version 0, edited 4 years ago by hakre (next)

comment:14 @techgurufloyd4 years ago

My server is behind a couple of reverse proxies - one sends it to the chache, the other to the app server farm when the cache doesn't have the request. HTTP_HOST will never be accurate in that environment. Shouldn't WordPress use SERVER_NAME instead? Or perhaps offer an option to use SERVER_NAME or HTTP_X_FORWARDED_HOST instead of HTTP_HOST? There's also the option of using the server name I put in the WP options.

The ugly hack I'm using in wp-config right now to get around this:

//UGLY HACK:
$_SERVER['HTTP_HOST_ORIG'] = $_SERVER['HTTP_HOST']; //Might as well keep it around, but whatever.
$_SERVER['HTTP_HOST'] = $_SERVER['SERVER_NAME'];    //The important part.

Would WordPress be open to some kind of configuration option that selects which Header to use? If so, I can generate a patch that replaces every instance of HTTP_HOST with something that uses such an option.

Another idea would be to set $_SERVER['WP_HOST'] to be whichever header is chosen, and do a quick sed to change HTTP_HOST to WP_HOST. That still feels hackish, but it would work. Whatever solution is chosen, I'm looking for something that gets in the core.

comment:15 in reply to: ↑ 10 @amirhabibi4 years ago

Replying to hakre:

I have the feeling that what you describe for the preview redirect is another issue. Please open a new ticket for it and leave the new ticket number here. Looks like something is incompatible on your setup with the wordpress preview feature, probably because of your host configuration.

Yes. You were right. The preview problem was caused by the Squid server refusing cookies.

Thanks a lot for all ;-)

comment:16 @tobias3 years ago

  • Cc t@… added

This ticket is a duplicate or strongly related to http://core.trac.wordpress.org/ticket/18944#comment:7

And at http://core.trac.wordpress.org/ticket/17168#comment:15 I suggested not to use HTTP_HOST in the core at all but to switch to a variable that is configured in wp-config at one central place.

comment:17 @DrewAPicture10 months ago

  • Owner set to dd32
  • Status changed from reopened to reviewing

@dd32: Care to followup here?

Note: See TracTickets for help on using tickets.