Include actions logged by AbuseFilter in the CheckUser results page
Closed, ResolvedPublic

Description

The abusefilter saved the ip address for each logged action. You can see that ip address with the abusefilter-private user right, but that right is not used on wmf wikis, because it provides unlogged access to user IP addresses of each logged action.

To see ip addresses of users the wmf wikis are using the CheckUser extension, which restricted and logged the access. So in my opinion each entry of the abuselog should also create an entry for CheckUser, to make the ip address of logged actions searchable.

It is possible to include the logged action from abusefilter into the CheckUser report?

Thanks.


Version: unspecified
Severity: minor

bzimport set Reference to bz29583.
Umherirrender created this task.Via LegacyJun 25 2011, 3:45 PM
csteipp added a comment.Via ConduitAug 16 2012, 1:34 PM

User Trijnstel also requested this. He additionally added:

"It's not my intention to (automatically?) check all abusefilter logs (which
was something the abusefilter-private right did). I would like to see the logs
itself in the "edits" section of the CheckUser form. For example: if you check
a user on his edits, you'll get his regular edits, any log actions such as
account creation and emails he send. But you doesn't see the abuse log entries.
And that's something I would like to see in the results. Now the log entries
are completely ignored, just as if they didn't exist. You don't see them via
the edits, nor do you see them via the users section. So I don't want to check
on abuse log entries - like IP's/Edits/Users/Abuse Log; I only want to have the
abuse log entries visible in the edits section."

csteipp added a comment.Via ConduitAug 16 2012, 1:36 PM
  • Bug 39343 has been marked as a duplicate of this bug. ***
Umherirrender added a comment.Via ConduitAug 16 2012, 3:52 PM

(In reply to comment #2)

  • Bug 39343 has been marked as a duplicate of this bug. ***

Right number?
Because I am getting "You are not authorized to access bug #39343.", if that is the right bug, please make it visibe. Thanks.

csteipp added a comment.Via ConduitAug 17 2012, 8:39 PM

Bug 39343 was opened as a security bug, and contains private information of a spam bot that the reporter was using as an example. I included the relevant pieces, without the private data, in Comment #1. Sorry for the confusion!

Legoktm added a comment.Via ConduitDec 19 2012, 7:50 PM

The easiest way to do this would be to send AbuseFilter hits to RecentChanges, at which point CheckUser would pick them up, however that would also cause them to show up in RecentChanges, which might not be what is wanted (also the public vs. private issue).

The other way would be to have AF manually create the RecentChanges object and have the CheckUser extension call a AF hook (that would need to be written) which gets it.

Snowolf added a comment.Via ConduitDec 20 2012, 10:16 AM

In the long term, the best way going forward would be to not have the CheckUser extension rely on RecentChanges. It seems to me that as for late we're getting more and more tools that do not log to the RecentChanges (Abuse filter, Article Feedback Tool)

gerritbot added a comment.Via ConduitOct 26 2013, 7:01 AM

Change 92053 had a related patch set uploaded by Legoktm:
Send AbuseFilter hits to CheckUser

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

gerritbot added a comment.Via ConduitDec 26 2013, 10:13 PM

Change 92053 merged by jenkins-bot:
Send AbuseFilter hits to CheckUser

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

Legoktm added a comment.Via ConduitDec 27 2013, 7:33 AM

Should go out with 1.23wmf9. Note that only filter hits after this change is deployed will show up in CU results.

Billinghurst added a comment.Via ConduitDec 27 2013, 10:35 AM

Sweeeeet. Thanks.

Add Comment