Hi, I was testing something on my personal wiki regarding 'createaccount' AbuseFilter blocks.
I tried to unblock an IP that had been blocked by AbuseFilter when performing a 'createaccount' action using Special:AbuseFilter/revert. The system told me that I had successfully reverted the actions. However, the IP was not unblocked.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Fix reverting consequences for createaccount | mediawiki/extensions/AbuseFilter | master | +20 -3 |
I think I know what is wrong. It blocks the IP address, but the abuse log entry refers to the account name and hides the IP address by default.
The system told me that I had successfully reverted the actions.
Yeah, it says so. But the truth is the "success" boolean values are ignored. We need to improve it.
Change 955867 had a related patch set uploaded (by Matěj Suchánek; author: Matěj Suchánek):
[mediawiki/extensions/AbuseFilter@master] Fix reverting consequences for createaccount
@SRuizR: Someone needs to review https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/955867 . See https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews
Resetting task status from "In Progress" to "Open" as this task has been "in progress" for more than one year (see T380300). Feel free to set that status again, or rather break down into smaller subtasks.
This task may be quite important for T413695: AbuseFilter should have a revert API. It's a bit tricky to resolve the merge conflict in Block::revert though, as the method now uses UnblockUserFactory::newRemoveBlock and ManualLogEntry is no longer used there.
Indeed, but we are not really bound to use that interface (notice that the code uses UnblockUser::unblockUnsafe which is actually marked as @internal).
... not really. The UnblockUser does a lot more, including running hooks. We need to make a change in the core first, otherwise this is a dead end. (The priority isn't very high as Wikimedia now enforces temporary accounts.)
Yeah, we probably need to add an UnblockUser counterpart of BlockUser::setLogDeletionFlags to address this.
BTW, to my understanding the block consequence for account creation targets the underlying IP?