Blocks performed by the AbuseFilter show up in the Checkuser as having been performed thru the target's IP address, hence it appears as if the IP had been used by more than one user, one being the actual user and the other being AbuseFilter blocking it.
This causes some confusions and several times I've performed the additional check on the IP trying to figure out who else used it.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T60272 127.0.0.1, ::1, localhost, loopback, lo0 bugs (tracking) | |||
| Resolved | Dreamy_Jazz | T44345 Blocks from AbuseFilter show up as performed from the target's IP address in Checkuser | |||
| Resolved | Dreamy_Jazz | T311340 Allow the CheckUser extension to store an IP other than the IP from the request |
Change 92050 had a related patch set uploaded by Legoktm:
Allow extensions to override the IP address
Change 92051 had a related patch set uploaded by Legoktm:
Override the IP for the filter user in CheckUser data
Change 92179 had a related patch set uploaded by saper:
Allow robotic Users to determine their IP address
I did some checks here and the problem is thet a whole original WebRequest is re-used for logging.
Even if we force the AbuseFilter to give different IP address, for example user agent will be taken from the original request.
Change 92179 abandoned by saper:
Allow robotic Users to determine their IP address
Reason:
as per review
Change 92252 abandoned by saper:
Introduce AbuseFilterUser
Reason:
Thank you, closing per code review.
status update: two of the patches have been abandoned, but this one is still under review
Adding CheckUser.
Patches currently existing are gerrit:92051 in AbuseFilter and corresponding gerrit:92050 in CheckUser extension (Though they also currently reuse the same web request (same UA etc.).
Change 92050 had a related patch set uploaded (by Paladox):
Allow extensions to override the IP address
Change 92051 had a related patch set uploaded (by Paladox):
Override the IP for the filter user in CheckUser data
Krenair asked in Gerrit: "What about X-Forwarded-For?"
Anybody having an opinion / input?
I'm not sure how x-forwarded-for is relevant? Is Krenair suggesting that we should use x-forwarded-for to convey this info, or rather, that we need to account for x-forwarded-for headers in some way? It seems related but I'm not sure how it's relevant.
I think what @Krenair meant was "why not use/inject X-Forward-For to show both the IP that actually did the action (server's) and the IP of the user on whose behalf the server did the action (in this case I guess the blocked user?)
But I think that is not a good idea. XFF is used to show information flow form one IP to the next. In this case, the information does not flow to the blocked user at all so they should not be represented in the XFF trail.
The ability for AbuseFilter to do this is possible as AbuseFilter can use 'CheckUserInsertForRecentChange' to modify the cuc_ip (the user's IP) before insertion into the DB. It would be in charge of also updating the hex representation and the XFF. It may be better to make a hook that instead just allows specifying the IP so that CheckUser can be incharge of setting the hex value / XFF as appropriate. Discussion on which method is wanted is best had at the parent ticket T311340.
The IP stored could be a internal or invalid IP. It is at the moment possible to check 127.0.0.1 and as such sending software defined actions there may not be desirable. Instead storing an empty string as the IP could be a way to deal with this. The lack of content in cuc_ip could then be used to indicate to the software to show that it was an internal action / made by the software.
I don't see any reason why someone would need to run a check on actions performed by the software as there wouldn't be CU specific information that would be not representing that the software did this action. The IP would indicate that the software did this, and the user agent and XFF would both be blank or indicate that it was the software performing the action. Apart from that there isn't anything else that would be hidden as Special:Log would show the block entry.
Change 92050 abandoned by Dreamy Jazz:
[mediawiki/extensions/CheckUser@master] Allow extensions to override the IP address
Reason:
Done via dc7852f27d21f8dcc97f936f3119424068eabe2f
Change 854580 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/AbuseFilter@master] Change the IP, XFF and UA for CheckUser when performed by the abuse filter user
Change 854580 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Ensure IP, XFF and UA are valid for abuse filter user actions in CheckUser
Change 876333 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):
[mediawiki/extensions/AbuseFilter@master] Hook on privateEvent and logEvent insert hooks like CuChangesInsert
Change 876333 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Hook on privateEvent and logEvent insert hooks like CuChangesInsert
Change 92051 abandoned by Matěj Suchánek:
[mediawiki/extensions/AbuseFilter@master] Override the IP for the filter user in CheckUser data
Reason:
The bug has already been fixed