Page MenuHomePhabricator

The Special:AbuseLog search function does not return or display "createaccount" or "autocreateaccount" edit filter logs when filtering by username
Open, Needs TriagePublic



When you filter the edit filter log (AKA Special:AbuseLog) by entering the username of an account as a search condition, no "createaccount" or "autocreateaccount" edit filter hits by that account are displayed on the log page if the resulting action was not to prevent the account creation from occurring.


This may be a duplicate task to another that I just didn't find when searching on here, and if this is the case, please accept my apologies. This has been an issue that I noticed awhile ago and know has existed for some time now.

When clicking on the "filter log" button on an account's contributions page (see image 1), or when you visit the filter log through Special:AbuseLog and manually filter the search to only list logs that were made by the specific username of an account, the resulting abuse log page does not display any edit filter hits by that account if they are "createaccount" or "autocreateaccount" hits (see image 2), and if those filters also were not set to prevent the account creation action from occurring. However, if you modify the filter and remove the username as a filter condition, the abuse log will be found and listed (see image 3). What's bizarre is the fact that searching the filter log with a username that does not exist or belong to an account (see image 4) will correctly return "createaccount" abuse filter logs if an account creation attempt was made but was blocked by the given filter due to meeting the conditions set (see image 5).

Edit filters with "createaccount" or "autocreateaccount" conditions that are not set to intervene and prevent the creation from occurring will still create an entry in the edit filter log when a positive hit is identified. These entries should appear when a specific username is entered into the search function on the edit filter log page, and regardless of whether or not the username is to an account that currently exists. Users should be able to search the edit filter log, narrow the results by a given username, and all edit filter log entries involving the entered username should return and display on the resulting abuse filter log page. The issue I'm reporting shows that this is currently not the case.

Reproduction steps

An example you can use to reproduce the issue is with an account I just blocked here (we'll call this "Account 1"), as well as this account that I found here (we'll call this "Account 2"). Account 1 tripped edit filter 51 (which does not intervene or block the account creation action) and was created as usual and later blocked. Account 2 tripped edit filter 874 (which blocks the creation action if hit), and was not created (and hence does not exist). Here are the reproduction steps that you can use to identify and prove the issue being reported in this ticket:

  1. On the user contributions page for the account with username "Julekafuck off" ("Account 1"; the link is here), click on "filter log" (see image 1). No results will be found (see image 2).
  2. If you navigate to Special:AbuseLog and filter the results by filter ID #51 (or just click on this link), an entry for a "createaccount" hit made on 19:02, 18 October 2019 and for that same account will be found (see image 3).
  3. Add the username of Account 1 ("Julekafuck off") back to the abuse log filter as a search parameter so that it will filter the results by both the username and filter ID 51. The filter log does not return any results, and the same log that was found by filtering just by filter ID 51 (step 2 above) isn't listed.
  4. Navigate to the contributions page of "Account 2" (username is "North40 nowhere" - click here to go there). You'll see that a warning is displayed that no account exists with that username.
  5. Click on "filter log" (link is here). You'll see that a "createaccount" edit filter log entry exists and is correctly displayed on the log page as it should be, despite the fact that no account currently exists with that username. The filter disallowed the creation from occurring (as you can see in the log entry), yet this log entry is properly found and listed while the log entry from "Account 1" wasn't properly found and displayed, even though we filtered the search by the same parameter - username. The best conclusion to reach here is that there's an issue with the abuse filter log search function where filtering the log by username will not display "createaccount" filter logs if the filter action did not block the creation from occurring.

Image 1:

1.jpg (500×1 px, 188 KB)

Image 2:
2.jpg (1×1 px, 95 KB)

Image 3:
3.jpg (1×1 px, 161 KB)

Image 4:
4.jpg (396×1 px, 53 KB)

Image 5:
5.jpg (1×1 px, 112 KB)

Event Timeline

Seems the same as T213982? Long story short, the account creator is an IP address, hence filtering by user (where user = the name of the account being created) won't work. OTOH, the non-existing account has some entries in the AbuseLog because attributing them to the underlying IP would disclose personal info.

@Daimona - Oh snap. You're probably right that this might be the same thing as the other ticket you referenced. I feel like an idiot, since I authored the possible duplicate. *Facepalms at himself for the stupid that he might've done*

Sure, you're right that the account creator is technically an IP address at this point, since they're creating the new account with the given username. However, searching by username returns some "createaccount" filter logs hits and not others. This is inconsistent; it should return the relevant filter logs when a search parameter is entered for the username of the relevant account using the search function on the log page.

I'm obviously not referring to the IP address as being able to be searched for in the username field, as I agree that this would be a huge exposure of non-public information if that were possible. However, the username of the account that was either created or was attempted to be created (and was prevented by a filter from doing so) should return as a result when the username is searched for.