Last modified: 2011-03-13 18:05:17 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 8866 - Should be able to modify $wgServerName in LocalSettings.php
Should be able to modify $wgServerName in LocalSettings.php
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks: 19593
  Show dependency treegraph
 
Reported: 2007-02-03 17:01 UTC by Mark Clements (HappyDog)
Modified: 2011-03-13 18:05 UTC (History)
3 users (show)

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


Attachments
Patch for DefaultSettings.php (622 bytes, patch)
2007-02-03 17:03 UTC, Mark Clements (HappyDog)
Details

Description Mark Clements (HappyDog) 2007-02-03 17:01:29 UTC
I don't know if this is a general problem or a particular issue with the way my
shared host is set up, but $wgServerName (and therefore the variables that
depend on it) is being calculated incorrectly.

The code picks the first variable from this list that is defined (falling back
on 'localhost' if none of them are):

   $_SERVER['SERVER_NAME']
   $_SERVER['HOSTNAME']
   $_SERVER['HTTP_HOST']
   $_SERVER['SERVER_ADDR']

My company wiki is located on a protected sub-domain at
http://internal.mydomain.com/wiki/.  On our server the above variables are set
as follows:

   $_SERVER['SERVER_NAME'] = "www.internal.mydomain.com"
   $_SERVER['HOSTNAME']    = (not set)
   $_SERVER['HTTP_HOST']   = "internal.mydomain.com"
   $_SERVER['SERVER_ADDR'] = (IP address)

The order of checks mean that the automatically generated value is
"www.internal.mydomain.com" instead of just "internal.mydomain.com" as it should
be.  Because of the .htpasswd protection we are therefore asked to login twice,
as these are treated as separate domains.

I experienced the problem in 1.5.6, but I've checked HEAD and the code for
generating $wgServerName has not changed.
Comment 1 Mark Clements (HappyDog) 2007-02-03 17:03:32 UTC
Created attachment 3175 [details]
Patch for DefaultSettings.php

A patch to move the test for SERVER_NAME to after HTTP_HOST.  This is a
complete fix, providing that this behaviour is acknowledged to be a bug, rather
than intended behaviour.
Comment 2 Brion Vibber 2007-02-03 19:38:35 UTC
HTTP_HOST is unreliable generally as it is client-supplied; thus on a
configuration where strictly-enforced name-based virtual hosts are not being
used it may be possible for an attacker to poison caches (bad redirects, HTTP
response splitting, etc).

You probably should take a look at your Apache configuration and find out why
your ServerName is set differently to what you actually wanted to use.
Comment 3 Mark Clements (HappyDog) 2007-02-06 00:12:18 UTC
OK - I will look into that and return here with my findings.  Please leave this
bug open for the time being - I will update it when I've dug a little deeper.
Comment 4 Marti Raudsepp 2007-09-04 16:15:58 UTC
There is another reason why SERVER_NAME could be unreliable: when using HTTPS, the lighttpd web server sets SERVER_NAME to the SSL certificate's common name instead of the virtual host's name, which might be something like "*.example.org", thus again breaking redirects.

So, to allow serving over HTTP as well as HTTPS, one would have to set:
  $wgServer = $wgProto . "://wiki.example.org";
which is inelegant in my opinion. Changing $wgServerName alone has no effect, since its value is only used in LocalSettings.php to set $wgServer.

I would prefer either:
1. preferring HTTP_HOST over SERVER_NAME, or
2. making $wgServerName overridable, and thus assigning to $wgServer
Comment 5 Brion Vibber 2007-09-04 21:21:36 UTC
Well, for handling the two-available-URLs case you really want to do a little more, introducing the concept of a canonical URL base that's distinct from the currently active URL. Otherwise you end up with some weird mixes of getting one or the other saved in caches, sent in e-mails, etc.

I did a little experimenting with this in a short branch:

http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=23079

http://svn.wikimedia.org/viewvc/mediawiki/branches/ssl-login-work/

Haven't done any further work on that.
Comment 6 Marti Raudsepp 2007-09-07 10:45:05 UTC
I see your point about cache corruption. I'll have a look at your SSL branch when I can find the time. Thanks.
Comment 7 Mark Clements (HappyDog) 2008-03-28 12:09:07 UTC
Note that the issue with "www." being prepended to the domain (so "internal.mydomain.com" is reported as "www.internal.mydomain.com") seems to be a peculiarity with the way my server is setup, so I am getting round it by manually setting $wgServer.

As mentioned in comment 5, it would be better if I could just set $wgServerName rather than building $wgServer using the literal name, plus the protocol and port options, so I guess that issue still stands.  I have modified the subject to make the current issue clearer.
Comment 8 Dan Jacobson 2009-07-13 15:29:11 UTC
(In reply to comment #7)
>I have modified the subject
Well all I know is in bug 19593 I was able to modify $wgServerName in LocalSettings.php, so please modify the Summary again.

Comment 9 Alexandre Emsenhuber [IAlex] 2010-11-09 18:08:46 UTC
Marking as WONTFIX since $wgServerName was removed in r73950.
Comment 10 Dan Jacobson 2010-11-10 23:52:17 UTC
Added "blocks" just for reference to this already solved issue.

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


Navigation
Links