Page MenuHomePhabricator

Investigate: Update AntiSpoof for IP Masking
Closed, ResolvedPublic



We need to investigate how AntiSpoof may need updating for IP Masking.

From a product perspective, read the documentation and try out the product. Consider whether any changes may need making for temporary account users.

From a technical perspective, check where the search terms from T326759 appear, and consider whether these places appear to need updating.

These instructions are left intentionally vague to avoid biasing the investigation.

Outcome of this investigation
  • Write up a summary of findings
  • Raise any questions
  • File tasks if there is anything obvious to file

Event Timeline

I tested this by installing antiSpoof extension, then I ran through examples that can cause spoof conflicts.
I left the log around the code that eventually brings up these messages antispoof-*-*.
I got two instances of possible hit as listed from this patch T326759.

  1. $user->getName, which is called in a couple of places. This has no call of either isAnon or isRegistered or any other related functions.

The getName function that gets called is one under user.php in core here

  1. Which calls one of IPutils functions here

here too the sanitizeIP function is static and does not call any functions on the user object or any function that will affect IPMasking.

Given the above it does not look like anything is needed to be done for antiSpoof to work with IP Masking

AntiSpoof stores for each registered user a row in its table spoofuser. The question could be if that is needed for temp users as there is never the need to detect a conflict with similiar named users. When not doing it, it would save some space on the database. Whenever the pattern for temp user is changed the maintenance script is needed to fill in the missing user names.

In that case: To save some space a call to isNamed needed to store only named users in the database (in SpoofUser class) and something similiar in the maintenance script.

The $wgAutoCreateTempUser option allows to specify a matchPattern which avoid user creation with that pattern, so there maybe is no need for AntiSpoof to prevent usernames similiar to temp users (not for default config).
For custom pattern not beginning with a special letter like * that maybe could be relevant to check the user name (by using the equivset), that is also valid to do later or never.