Page MenuHomePhabricator

Special:Contributions no longer accepts display form of IPv6 addresses
Closed, ResolvedPublicBUG REPORT


Steps to reproduce:

  1. View an edit, such as this.
  2. Copy the displayed IP address, e.g. from a discussion comment signature, or from the diff, or the history page, or recent changes, or elsewhere in the interface. 2600:1004:b14a:5ddd:3ebe:bba4:bfba:f37e
  3. Open Special:Contributions and paste it in the form. Or, as power user, one might have an existing contributions query open and paste it in the address bar as /wiki/Special:Contributions/ <paste here>

Actual results:

Nothing, no edits?

Expected results:

The edits in question.


It turns that the query only works when the address is in the internal uppercase format, which is generally not displayed to users. So the above edit is accessible via the following instead:

Interestingly, even the "actual" result link above (lowercase IP) has a heading that says it is displaying results for the uppercase IP. It says "//2600:1004:B14A://…". The two pages look identical, except that one is broken and the other isn't. example:

which is the very same IPv6 address, just lowercase.

Event Timeline

This is a big issue and I hope that it receives priority for fixing.

Umherirrender added a subscriber: Umherirrender.

Possibly regression from, because the target is user input for the target is used and not normalized by Title::getText (which handles the case part in ips)

Change 656605 had a related patch set uploaded (by Ammarpad; owner: Ammarpad):
[mediawiki/core@master] Special:Contributions: Account for IP normalization

Krinkle renamed this task from Special:Contributions no longer ignores case on IPv6 addresses to Special:Contributions no longer accepts display form of IPv6 addresses.Jan 17 2021, 7:50 PM
Krinkle added a project: Growth-Team.
Krinkle updated the task description. (Show Details)

This is a serious issue still remaining in place. I searched for a template error first, then noticed that this is a MediaWiki regression. It causes problems at enwiki's vandalism report page, where bots like DatBot automatically create urgent reports with lowercase IPv6 addresses that are incorrectly interpreted as non-actionable.

MMiller_WMF added subscribers: Tgr, MMiller_WMF.

@Tgr is going to code review the patch this week.

This comment was removed by Tgr.

The uppercase variant is somewhat standard: for example redirects to it. This is handled by MediaWikiTitleCodec sending User namespace page names through IPUtils::sanitizeIP (which might perform other changes as well, since IPv6 addresses have abbreviated forms).

I think the breakage is caused when ContribPager turns the target string into a User and passes it to ActorMigration::getWhere which uses it as is to match actor_name. That broke during the commit @Urbanecm indicated.

It would be nice to handle this on a low level to avoid future problems, and normalize IPs in User::$name (seems scary) or in ActorMigration::getWhere and ActorMigration::getNewActorId (less scary).

Change 658486 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/core@master] Normalize IP addresses before writing/reading actor.actor_name

Adding the platform team for visibility since they maintain User and ActorMigration.

Change 656611 had a related patch set uploaded (by Gergő Tisza; owner: Ammarpad):
[mediawiki/extensions/GlobalContribs@master] Pass normalized target username to contributionsSub()

Change 656605 merged by jenkins-bot:
[mediawiki/core@master] Special:Contributions: Pass normalized target to ContribsPager

Change 656611 merged by jenkins-bot:
[mediawiki/extensions/GlobalContribs@master] Pass normalized target username to contributionsSub()

@Tgr Thanks! Should we backport?

This is a minor bug and the regression happened three weeks ago, it can wait another week IMO.

Change 658486 merged by jenkins-bot:
[mediawiki/core@master] Normalize IP addresses before writing/reading actor.actor_name

Ammarpad raised the priority of this task from Low to Medium.

Not yet, wmf.29 had some issues and is not rolled out yet (T271343)