Page MenuHomePhabricator

Normalise IP addresses in HTMLUsersMultiselectField, to avoid adding multiple equivalent IP addresses
Closed, ResolvedPublic

Description

It is not possible to add multiple equivalent usernames twice using the JS UsersMultiselectWidget, e.g. "Admin 1" and "Admin_1". Since T274568, this is also the case for the PHP widget.

However, in both modes, the widget treats equivalent IP addresses as separate entries:

image.png (100×720 px, 10 KB)

This is problematic because:

  • Anything that handles the widget's values needs to ensure that the IP addresses are unique
  • If the widget has a limit set, it uses up extra entries for equivalent IPs

An example of where equivalents are (unintentionally) treated as two separate IP addresses downstream can be found in CheckUser:

image.png (146×381 px, 9 KB)

Event Timeline

Niharika moved this task from Untriaged to Triage/To be Estimated on the Anti-Harassment board.
Tchanders renamed this task from Normalise IP addresses in HTMLSUsersMultiselectField, to avoid adding multiple equivalent IP addresses to Normalise IP addresses in HTMLUsersMultiselectField, to avoid adding multiple equivalent IP addresses.Feb 23 2021, 4:58 PM

Change 672798 had a related patch set uploaded (by TsepoThoabala; owner: TsepoThoabala):
[mediawiki/core@master] Normalise IP addresses in HTMLUsersMultiselectField

https://gerrit.wikimedia.org/r/672798

@dom_walden There's a known issue with the solution we've merged, i.e. that it doesn't solve this point for the JS widget:

  • If the widget has a limit set, it uses up extra entries for equivalent IPs

Filed separately as T278153

Change 672798 merged by jenkins-bot:
[mediawiki/core@master] Normalise IP addresses in HTMLUsersMultiselectField

https://gerrit.wikimedia.org/r/672798

We are now removing duplicate IPs of the form ::1 and 0:0:0:0:0:0:0:1, or 3e2b:a4:9ed7:bf36:4aca:5189:c496:5a05 and 3e2b:00a4:9ed7:bf36:4aca:5189:c496:5a05 when submitting Special:Investigate.

I checked that, after removing duplicates, we are still making the correct CheckUser database queries in the backend (for IPv4 and IPv6 addresses and ranges).

I briefly tested that we can still submit Usernames via Special:Investigate, and the bug in T274568 is still fixed.

Duplicates we are still not removing:

  • 192.168.1.2 and 192.168.1.2/32 are treated as different, even though technically they are the same (same goes for IPv6).
  • 192.168.123.0/24 and 192.168.123.123/24 are treated as different, even though they are the same (same goes for IPv6).

Test environment: local docker MediaWiki 1.36.0-alpha (0012150) 07:23, 23 March 2021; CheckUser 2.5 (60d4d16) 06:21, 13 March 2021.