Page MenuHomePhabricator

Viewing a User or User talk page of username resembling IP ending with ".xxx" causes internal error
Closed, ResolvedPublic

Description

Author: chzz

Description:
enwiki

Trying to display this page;

http://en.wikipedia.org/wiki/User_talk:213.253.39.xxx

Results in;


Internal error

From Wikipedia, the free encyclopedia

Tried to load block with invalid type

Backtrace:

#0 /usr/local/apache/common-local/php-1.18/includes/Block.php(1039): Block->newLoad('213.253.39.xxx')
#1 /usr/local/apache/common-local/php-1.18/includes/Article.php(646): Block::newFromTarget(NULL, '213.253.39.xxx')
#2 /usr/local/apache/common-local/php-1.18/includes/Article.php(570): Article->getRobotPolicy('view')
#3 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(479): Article->view()
#4 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(250): MediaWiki->performAction(Object(Article))
#5 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(635): MediaWiki->performRequest()
#6 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(542): MediaWiki->main()
#7 /usr/local/apache/common-local/php-1.18/index.php(57): MediaWiki->run()
#8 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')

#9 {main}

At time of writing, the page has only one revision, which is from 2007;

http://en.wikipedia.org/w/index.php?title=User_talk:213.253.39.xxx&diff=prev&oldid=145797301

Other IP user talks ending with .xxx give similar, including;

http://en.wikipedia.org/wiki/User_talk:216.195.179.xxx
http://en.wikipedia.org/wiki/User_talk:209.75.42.xxx

Originally reported at VPT;

http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Internal_error

http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=prev&oldid=465754254


Version: 1.18.x
Severity: critical

Details

Reference
bz33101

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:00 AM
bzimport set Reference to bz33101.
bzimport added a subscriber: Unknown Object (MLST).

Presumably, either parser or block module tries to interpret username as an IP adress. Marking as critical.

Created attachment 9703
Don't try to load blocks for an invalid username

It appears the problem will occur on any non-redlinked user or user talk page for an invalid username. Names like "209.75.42.xxx" are invalid because they were used by the usemod software to "cloak" IP addresses, but any other case where you can create the user or user talk page for an invalid username will do it.

The problem lies in Block, in that it will try to load blocks for what it already knows is an invalid username, and then complains when it finds that it has an invalid username. It was broken in the big rewrite in r84475.

I've attached a patch that quite simply just makes it return "no blocks" for an invalid username.

Attached:

What does "invalid" mean in this context? Obviously, these usernames exist, andthe can be blocked. So reporting no-blocks would be just as bad.

(In reply to comment #4)

What does "invalid" mean in this context?

Presumably, it means that the usernames can't be created anymore, per bug 3631.

(In reply to comment #2)

Created attachment 9703 [details]
Don't try to load blocks for an invalid username

It appears the problem will occur on any non-redlinked user or user talk page
for an invalid username. Names like "209.75.42.xxx" are invalid because they
were used by the usemod software to "cloak" IP addresses, but any other case
where you can create the user or user talk page for an invalid username will do
it.

The problem lies in Block, in that it will try to load blocks for what it
already knows is an invalid username, and then complains when it finds that it
has an invalid username. It was broken in the big rewrite in r84475.

I've attached a patch that quite simply just makes it return "no blocks" for an
invalid username.

Interesting, I couldn't reproduce locally on trunk, but pushing the fix to the cluster fixed the issue. So I'm gonna apply the patch based on that

r106354 and r106355

Thanks!

Attached:

chzz wrote:

(In reply to comment #6)

(In reply to comment #2)

Created attachment 9703 [details]
Don't try to load blocks for an invalid username

It appears the problem will occur on any non-redlinked user or user talk page
for an invalid username. Names like "209.75.42.xxx" are invalid because they
were used by the usemod software to "cloak" IP addresses, but any other case
where you can create the user or user talk page for an invalid username will do
it.

The problem lies in Block, in that it will try to load blocks for what it
already knows is an invalid username, and then complains when it finds that it
has an invalid username. It was broken in the big rewrite in r84475.

I've attached a patch that quite simply just makes it return "no blocks" for an
invalid username.

Interesting, I couldn't reproduce locally on trunk, but pushing the fix to the
cluster fixed the issue. So I'm gonna apply the patch based on that

r106354 and r106355

Thanks!

Gosh, it's a whole other language. As a mere human. I have no idea about your
'pushing trunks' and so forth; I can only thank you for your kind attention

Attached:

(In reply to comment #4)

What does "invalid" mean in this context? Obviously, these usernames exist,
andthe can be blocked. So reporting no-blocks would be just as bad.

In this context, "invalid" means "User::newFromName($name) returns false". I'm not sure how well an existing account with such a name would be usable, as anything that tries to use User::newFromName to get at the user data will break.

(In reply to comment #6)

Interesting, I couldn't reproduce locally on trunk, but pushing the fix to the
cluster fixed the issue. So I'm gonna apply the patch based on that

Did you make sure to create the user/user talk page on your local wiki?