When an user account is renamed, their pages are usually moved to the new name. Some wikis such as thwiki among others (see filter 17) have set filters to avoid users moving their user pages. This causes, on renames, that page moves needed to be performed get blocked by the abuse filter. Is there any way to exempt the page moves triggered by [Global]RenameUser from AbuseFilter? Thank you.
|mediawiki/extensions/CentralAuth : master||Make `onAbuseFilterShouldFilterAction` static|
|mediawiki/extensions/CentralAuth : master||Tell AbuseFilter not to filter moves during a rename|
|mediawiki/extensions/AbuseFilter : master||Temporarily exclude Jobs from TitleMove hook|
- Mentioned In
- T69936: Provide a sane way to bypass abuse filters
T232945: CentralAuth hooks function `onAbuseFilterShouldFilterAction` should be static
T229252: Let other extensions specify if the current action should be filtered or not
T204881: Failed executing job: AssembleUploadChunks "Disallowed by AbuseFilter"
- Mentioned Here
- T229252: Let other extensions specify if the current action should be filtered or not
T69875: GlobalRename: Page moves are being blocked by local abusefilters
T209488: Global rename of Massimo Telò → Teseo: supervision needed
T69936: Provide a sane way to bypass abuse filters
T204881: Failed executing job: AssembleUploadChunks "Disallowed by AbuseFilter"
This reminds me of T204881. Basically, the root problem here is that we don't have a way to exclude certain actions from filtering - some sort of T69936, but related to the code instead of the users. I cannot tell right now if it'll be difficult to implement such feature, but for sure I can say that it's worth spending some time thinking about it, instead of quickly providing a flaky solution. The stopgap here is tuning the offending filters, for instance by checking user_name, or global_user_groups.
UPDATE: Well, actually the user-based solution could be fine for this. If so, this is duplicate of T69936. Otherwise, we could add a hook to AbuseFilter (either before checking filters or before taking consequences), which CentralAuth could use to bypass the filter. Let's hear some thoughts.
@1997kB That's not strange: it's because we recently changed the hook used for filtering move actions. Before, we used to run filters when checking user's permissions, and that part is skipped by the Rename Job. Now, we run filters right before the move is executed, and this includes the Job's case. The change went live with 1.33-wmf.8 last week, so that's why it didn't happen before.
So...we had fixed this back in T69875: GlobalRename: Page moves are being blocked by local abusefilters.
This seems wrong. It was very intentional that AbuseFilter ran during the user permission check, because it actually depends upon the specific user. I think the rationale in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/472668 is wrong, specifically "We're not really checking permissions" given that many filters do in fact check permissions.
Ah I didn't know this already happened in the past.
As for the checking permission thing, I'm not convinced. To me, checking permissions means deciding whether the user is allowed to move the page based on their rights, if they're blocked etc., not checking filters which could also make use of such things. It's also true that filtering depends on the user performing the action, and that many filters do check permissions (but not as their only check, I hope), but still I don't think this can be considered "checking permissions". Also, note that the main reason which lead to the patch is in the associated task. Sure, it could have been resolved in other ways, but I wanted to kill two birds with a stone; two birds and a half if we take into account the confusing message we used to show users when they hit the filter.
That being said, I still think that the proper solution is creating a way to bypass abuse filters; maybe, both a code-based way (e.g. a new AbuseFilter hook) and a user-based way.
@1997kB You may ask for that filters to be changed by local filter managers. It should be enough to check global_user_groups. A proper fix is building a way to bypass AF, and we should plan it well. For sure, nothing will change for these two weeks, since there won't be deployments (and the patch needs to be written and reviewed).
@Daimona : There are 7 of them triggering rn. If you want to fix, I have mentioned some of them in my message above. @Lymantria : This one on zhwiki is fixed (1). But there could be more, yesterday I found one on metawiki (2) triggering for a renamer whois isn't much active there, so it depends upon local edits of renamer.
As for Meta I did https://meta.wikimedia.org/wiki/Special:AbuseFilter/history/87/diff/prev/2053 which I hope excludes global renamers/stewards from it. Although Adavyd's case is not very common as global renamers usually have more than 20 edits on Meta before being appointed :) Hope that such fix is okay, otherwise please let me know.
As for the filters on other wikis, if you let us know what 'exactly' needs to be done we could discuss if we can do it ourselves. We ain't supposed to modify local abusefilters. Note that global renamers are a local user group on Meta, so excluding via user_rights/global_user_group is not an option for wikis other than Meta.
Since this is meant to be a temporary workaround, anything that works is fine. For instance, checking the summary against the default summary for renames (quick but easy to bypass), or checking that the user name belongs to the list of global renamers manually (longer but safer).
I'm trying to figure out if there's an acceptable workaround for the moment, as the "abusefilter-exempt" thingy is tricky.
@Daimona @1997kB This abuse filter log https://nl.wikipedia.org/wiki/Speciaal:Filterlogboek/1426739 suggests that there is no edit summary ("bewerkingssamenvatting") that can be used to exclude from the filter. I am reluctant to list a couple of names of global renamers, which will be hard to keep up to date. I therefore have deactived the filter at nlwiki for now.
That's weird, because the Job seems to use centralauth-rename-movelog as summary, without making it possible to change it. Anyway the hack above should solve the problem, at least for now.
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/482408/ isn't merged yet. But if AF is no longer blocking page moves during renames, maybe something else was merged that made this superfluous -or- we ain't triggering those filters anymore.
Mistakenly checked that earlier gerrit link and thought it's no more happening, but it is not yet fixed. Checked some filter and they still triggering, although I haven't triggered on recent rename having account on 735 wikis. Sorry for unnecessary ping.
@Daimona a potential implementation that doesn't require any code changes:
- Convert the global-renamer group to be a global user group
- Restrict the wikiset for the global-renamer group to just metawiki
- Exempt users in the global-renamer group from the abuse filters
Even if a wiki isn't part of a global group's wikiset, abusefilter still has access to that global group - see https://en.wikipedia.org/wiki/Special:AbuseFilter/examine/1171433212, where a global sysop moves a page on enwiki. In the global_user_groups field, global-sysop is included despite not applying to enwiki.
Yeah, making it a global group has already been taken into account. However, that's not the best solution. IMHO, it's better to just exclude jobs altogether, like the patch above does for move actions.
Ideally, I believe we should provide a hook like AbuseFilterShouldFilterAction or smth like that, and other extensions should use it to tell whether the current action should be skipped.
This way it'd also work for non-move actions, without having to blindly allow all jobs.
OK, so I sent a patch for T229252. With that in place, all we need is a patch in CentralAuth, adding a handler for the new hook, where we should determine whether the current action is a global rename. I'm not familiar with CA, so I don't know how that should be done, but we can try to add hook params if needed. Just, please, avoid lame stuff like checking the summary because that'd be exploitable.