Page MenuHomePhabricator

Login form barfs on malformed REMOTE_ADDR
Closed, DeclinedPublic

Description

Author: safemailto-mediawiki

Description:

Problem:

When I set Monobook as default skin (or other skin based on Monobook template), MediaWiki crashes everytime I click in Login/Create an Account link.

Configuration:

  1. Windows Vista SP1
  2. IIS Server 6.0
  3. MediaWiki 1.14.0
  4. PHP Version 5.2.6
  5. MySQL 5.1.26

Error message:

MediaWiki internal error.

Original exception: exception 'MWException' with message 'SkinTemplate::makeTalkUrlDetails given invalid pagename User:' in C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php:624
Stack trace:
#0 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(564): SkinTemplate->makeTalkUrlDetails('User:')
#1 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(434): SkinTemplate->buildPersonalUrls()
#2 C:\inetpub\wwwroot\intranet\wiki\includes\OutputPa ge.php(945): SkinTemplate->outputPage(Object(OutputPage))
#3 C:\inetpub\wwwroot\intranet\wiki\includes\Wiki.php (342): OutputPage->output()
#4 C:\inetpub\wwwroot\intranet\wiki\index.php(115): MediaWiki->finalCleanup(Array, Object(OutputPage))
#5 {main}

Exception caught inside exception handler: exception 'MWException' with message 'SkinTemplate::makeTalkUrlDetails given invalid pagename User:' in C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php:624
Stack trace:
#0 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(564): SkinTemplate->makeTalkUrlDetails('User:')
#1 C:\inetpub\wwwroot\intranet\wiki\includes\SkinTemp late.php(434): SkinTemplate->buildPersonalUrls()
#2 C:\inetpub\wwwroot\intranet\wiki\includes\OutputPa ge.php(945): SkinTemplate->outputPage(Object(OutputPage))
#3 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(159): OutputPage->output()
#4 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(183): MWException->reportHTML()
#5 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(269): MWException->report()
#6 C:\inetpub\wwwroot\intranet\wiki\includes\Exceptio n.php(327): wfReportException(Object(MWException))
#7 [internal function]: wfExceptionHandler(Object(MWException))
#8 {main}

Overview:

It is a strange behavior: using Monobook skin, MediaWiki creates a cookie named "wikidb_session". This cookie holds some configuration and its is the responsible for crashes the interface when click "Login/Create an Account link". After the problem, all pages crashes for complete. If I delete the cookie, interface runs again. But, as soon I click the login link again, interface crashes.

This problem only happens with Monobook skin and some other skins using Monobook as template skin.

Done:

I disabled accept cookies in browser. Problem still happens when i click the link. But, now, without the cookie, all other pages runs perfectly.

Something are been trying to be generated when I click login link. I read in a forum something about this. I read about MediaWiki are trying to create a page, but it does not exist (Special:User). I can't confirm because i don't know MediaWiki functions deeply yet. I am studying.

I've done some tests last night, but without success. I copied all variables from "DefaultSettings.php", one by one, analyzed each one, and pasted into "LocalSettings.php" testing different values and it results. What was "false" by default, i tried "true" and vice-versa. And nothing, absolutely nothing, make any difference. Of course, some configurations cause MediaWiki stop for complete, but i cant solve this issue mentioned in this post. Still looking for and going to Bugzilla to post this bug.


Version: 1.14.x
Severity: major
OS: Windows Vista
Platform: PC

Details

Reference
bz18173

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:31 PM
bzimport set Reference to bz18173.
bzimport added a subscriber: Unknown Object (MLST).

phillip wrote:

This appears to be a regression, I tested this with an earlier version I still had save (1.9.2) and I did not get this exception.

phillip wrote:

MW 1.10.0 is the first version I observe this exception in, although it is handled gracefully. MW 1.14.0 just pukes on the exception. Here are the details from 1.10.0

SkinTemplate::makeTalkUrlDetails given invalid pagename User:

Backtrace:

#0 C:\inetpub\wwwroot\wiki.10\includes\SkinTemplate.php(561): SkinTemplate->makeTalkUrlDetails('User:')
#1 C:\inetpub\wwwroot\wiki.10\includes\SkinTemplate.php(436): SkinTemplate->buildPersonalUrls()
#2 C:\inetpub\wwwroot\wiki.10\includes\OutputPage.php(676): SkinTemplate->outputPage(Object(OutputPage))
#3 C:\inetpub\wwwroot\wiki.10\includes\Wiki.php(296): OutputPage->output()
#4 C:\inetpub\wwwroot\wiki.10\index.php(90): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage))
#5 {main}

It is the same first exception as 1.14, however, there is not a second exception thrown in the exception handler as in 1.14

phillip wrote:

Minor correction to the previous update:
MW 1.10.0 only handles the Exception gracefully the first time you encounter it when requesting the login page, the data in the cookie causes the second exception and the puke of trace details when requesting any other page afterwards, until the browser cache is cleared.

I further tested against 1.9.6 (which appears to be the last version prior to 1.10.0) and I did not get this exception at first. When I accessed the login page a second time (without logging in the first time) I get this exception:

PHP Fatal error: Call to a member function getTalkPage() on a non-object in C:\inetpub\wwwroot\wiki\includes\SkinTemplate.php on line 607

This prompted me to test again in 1.9.2 which was the version I started with, and I get the same behavior with this new exception. I'm beginning to think no version will work on this environment.

Here are my testing environment details:
Windows Server 2008
IIS Server 7
PHP Version 5.2.9-1 (IIS FastCGI)
MySQL 5.0.26-community-nt

I'm leaning towards an OS-level problem, because Server 2008 is almost the same at its core as Vista. And they are both very different from previous Windows OSs.

safemailto-mediawiki wrote:

Hum, interesting posts. Problem occur in Windows Vista and Windows Server 2008. I have an old machine here with Windows XP. Maybe i can try to install this environment and see if MW crashes in Windows 2000 Professional too.

Phillip, as you said in your latest post, only clearing the cache of the browser you will can access other pages after the first exception. Until you clear the cache, all pages are crashing after the first crash.

I will run some tests with Windows 2000 Professional SP4, the most stable of all Windows, in my opinion.

cjp wrote:

Reproduced:

Server is FreeBSD 7.1-RELEASE-p4, Apache 1.3.41, PHP 5.29 (mod_php), MySql 5.0.77 (MyISAM), MW 1.14.0

Does not occur on IE 7 nor recent Firefox, only occurs on Safari 4 (don't have Safari 3 around to test), Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/528.18.1 (KHTML, like Gecko) Version/4.0 Safari/528.17

Workaround... $wgDefaultSkin = 'standard'; in LocalSettings.php

cjp wrote:

Update... I can reproduce this with Safari 4 beta *and* [Firefox Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.10) Gecko/2009042315 Firefox/3.0.10] only when utilizing a Squid 3.0/STABLE9 proxy. Problem does not occur when using direct IP connectivity nor through another vendor's (BlueCoat) proxy.

I wonder if a proxy in the mix is common to my problem and the others who have reported it.

cjp wrote:

Response via Squid/3.0.STABLE9 for GET http://wiki.0x1.net/index.php?title=Special:UserLogin&returnto=Main_Page : (note: disabled gzip,deflate on browser for these tests)

HTTP/1.0 200 OK
Date: Thu, 04 Jun 2009 21:53:25 GMT
Server: Apache
Set-Cookie: db_mediawiki_session=f9360da5114ea391ec1223e3afd2f71e; path=/; HttpOnly
Content-Language: en
Vary: Accept-Encoding
X-Vary-Options: Accept-Encoding;list-contains=gzip
Content-Length: 1703
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from antenora.aculei.net
Via: 1.0 antenora.aculei.net (squid/3.0.STABLE9)
Proxy-Connection: keep-alive

MediaWiki internal error.<br /> ... ... ... etc.

Response when direct:

HTTP/1.0 200 OK
Date: Thu, 04 Jun 2009 22:03:18 GMT
Server: Apache
Set-Cookie: db_mediawiki_session=8c482a532baf758dfd44f906ec538a86; path=/; HttpOnly
Content-Language: en
Vary: Accept-Encoding,Cookie
X-Vary-Options: Accept-Encoding;list-contains=gzip,Cookie;string-contains=db_mediawikiToken;string-contains=db_mediawikiLoggedOut;string-contains=db_mediawiki_session
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Content-Length: 9953
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

<!DOCTYPE html PUBLIC "-W3CDTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ... ... ... etc. proper login document follows

Is this some sort of strange cache directive issue?

Note: these are the responses from the point of view of the browser... I cannot do a packet capture on this server sadly.

cjp wrote:

It turned out that this was occurring on my installation due to hosting provider local-wonkyness. Hosting provider (nearlyfreespeech.net) was rewriting the REMOTE_ADDR environment variable to facilitate their reverse proxies being "transparent" to scripts that were unfamiliar with interpreting X-Forwarded-For headers. The unintended side affect of this was that when external proxies were also present, REMOTE_ADDR looked something like "127.0.0.1, 44.68.10.10", which is not normal. Mediawiki choked on this. A locally relevant patch was applied, resolving the issue.

YMMV, this may not be the same issue the others are experiencing. But check your REMOTE_ADDR anyway (by way of phpinfo() perhaps?).

That said, MediaWiki should likely not puke when presented with a malformed REMOTE_ADDR.

(In reply to comment #8)

That said, MediaWiki should likely not puke when presented with a malformed
REMOTE_ADDR.

Updating summary accordingly.

demon added a comment.Jun 11 2009, 3:20 AM

Fixed in r51725

demon added a comment.Jun 12 2009, 2:25 AM

Reverted in r51774.

Faking IPs is bad. Instead, we'll try to get the IP as best as possible from REMOTE_ADDR or HTTP_X_FORWARDED_FOR. Barring that, we cannot proceed without an IP address. An exception is now thrown if the IP cannot be determined.

jthiesen98 wrote:

I have experienced this happening as well on my MediaWiki 1.15.1 installation and seemed to be caused by REMOTE_ADDR returning an IPv6 address. I'm guessing this is not supported by MediaWiki. As a workaround I included the following option in my local settings file to disable the display of IP address in the header when not logged in:

$wgShowIPinHeader = false;