Last modified: 2011-03-13 18:06:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5130 - Choice of $wgServerName order gives problems - solution provided
Choice of $wgServerName order gives problems - solution provided
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Redirects (Other open bugs)
1.5.x
PC All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-28 17:29 UTC by Shamus Husheer
Modified: 2011-03-13 18:06 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Shamus Husheer 2006-02-28 17:29:21 UTC
The choice of data source for $wgServerName in DefaultSettings.php leads to
problems on some types of virtual hosts.  For example, I run a wiki hosted
www.nearlyfreespeech.net (unfortunately it is private, so I can't demonstrate a
test).  BTW - NFS are fantastic hosts.  Shameless plug, no I don't get anything
out of it, however I would like to support them and people hosted by them as
much as possible, hence solving this bug before reporting it!

My www.example.com/wiki/index.php page nicely generates my files, until such
time as I edit a page - then it redirects to
mywebsitename.cust.nearlyfreespeech.net/wiki/index.php and my user credentials
are all lost (both from .htaccess and from the wiki user login).  My pages also
now look like they're from mywebsitename.cust.nearlyfreespeech.net in the
address bar, which means people might bookmark something other the cannonical site.

A very simple solution is to re-order the choice of where the $wgServer is
generated to use HTTP_HOST first in DefaultSettings.php (what I am now using -
problem solved).

However I assume there is a _reason_ for this specific search order for the
$wgServer.

While fixing that, it might also be appropriate to look at the "generated by"
$hostname from function reportTime() in OutputPage.php - however in the code
there a reason is discussed for using $_SERVER['SERVER_NAME'] rather than
$_SERVER['HTTP_HOST']

If there are good reason for using one data source rather than another, please
add this as a comment in the code so that people like me can find it there when
we hack - and possibly an indication of what might get broken if we do change it
(i.e. what might be wrong with using $_SERVER['HTTP_HOST']?)

Cheers
Shamus Husheer


From "DefaultSettings.php"

/** URL of the server. It will be automaticly build including https mode */
$wgServer = '';

if( isset( $_SERVER['SERVER_NAME'] ) ) {
	$wgServerName = $_SERVER['SERVER_NAME'];
} elseif( isset( $_SERVER['HOSTNAME'] ) ) {
	$wgServerName = $_SERVER['HOSTNAME'];
} elseif( isset( $_SERVER['HTTP_HOST'] ) ) {
	$wgServerName = $_SERVER['HTTP_HOST'];
} elseif( isset( $_SERVER['SERVER_ADDR'] ) ) {
	$wgServerName = $_SERVER['SERVER_ADDR'];
} else {
	$wgServerName = 'localhost';
}


My changed search order, which fixes the problem (at least for me):


if( isset( $_SERVER['HTTP_HOST'] ) ) {
	$wgServerName = $_SERVER['HTTP_HOST'];
} elseif( isset( $_SERVER['HOSTNAME'] ) ) {
	$wgServerName = $_SERVER['HOSTNAME'];
} elseif( isset( $_SERVER['SERVER_NAME'] ) ) {
	$wgServerName = $_SERVER['SERVER_NAME'];
} elseif( isset( $_SERVER['SERVER_ADDR'] ) ) {
	$wgServerName = $_SERVER['SERVER_ADDR'];
} else {
	$wgServerName = 'localhost';
}
Comment 1 Brion Vibber 2006-03-02 02:16:58 UTC
The HTTP Host header is provided by the client and therefore 
generally unsafe.

*If* you're on a specific virtual host which only allows access by 
the expected hostname, it might be reliable. (But given how 
$_SERVER works, I wouldn't even bet on that.)

As a general case, it's not safe; there may be security issues such 
as cache poisoning (forcing a bogus full URL into the parser cache, 
a squid proxy, or other place where it might get served back to 
another user).

If your web server is giving you a bogus server name, you should 
override it manually. As a safety issue I'm not willing to rely on 
HTTP_HOST data by default.


Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links