Page MenuHomePhabricator

Some AbuseFilter entries on Wikidata wrongly attributed to localhost
Closed, DeclinedPublic

Description

Author: pinkampersand.wikimedia

Description:
https://www.wikidata.org/w/index.php?title=Special:AbuseLog&wpSearchUser=127.0.0.1

As you can see, 13 edits since August have been erroneously attributed to 127.0.0.1 in the AbuseFilter log. The diffs all seem to list the correct usernames, e.g. [1] and [2], and localhost contribs[3] doesn't show anything since a bug that was resolved back in June. None of these edits was blocked by the filter, so they all show up in the relevant contrib page, e.g. [4].

An infrequent issue in itself, but I'm setting it as major due to the possibility of larger underlying bugs. Downgrade if you disagree.

Oh, and CC'ing wikidata-bugs in case this turns out to be a Wikidata thing.

[1] https://www.wikidata.org/w/index.php?title=Q893459&diff=prev&oldid=71814820
[2] https://www.wikidata.org/w/index.php?title=Q6951563&diff=prev&oldid=81251419
[3] https://www.wikidata.org/wiki/Special:Contributions/127.0.0.1
[4] https://www.wikidata.org/wiki/Special:Contributions/Nte213


Version: unspecified
Severity: minor

Details

Reference
bz57815

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:35 AM
bzimport set Reference to bz57815.
bzimport added a subscriber: Unknown Object (MLST).

The problem is in UpdateRepoOnMoveJob. The edits appear as done from localhost because they're executed from queued job queue jobs and not in the context of the user.

I don't think that we can easily fix this without doing other horrible things.

We're just mirroring actions from other Wikis there, so that's not something we need to filter (actually we probably shouldn't filter this at all... maybe we should avoid passing these edits to the various edit filters).

Due to that I don't think that this is important at all.

Saper suggested that this bug might be related to what I saw on wikidata after a CU: lots of edits on 127.0.0.1, most of them related to updates after a move.

So I do think it's important to fix this...

(In reply to comment #3)

Saper suggested that this bug might be related to what I saw on wikidata
after
a CU: lots of edits on 127.0.0.1, most of them related to updates after a
move.

Those edits are from the same source, yes (essentially these are automated changes to Wikidata to keep us up to date with the Wikipedias)

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).

What's the current status of this?

Unchaged, and I don't see neither a (sane) way to fix this nor a real reason to.

Lydia_Pintscher changed the task status from Open to Stalled.Dec 27 2014, 4:48 PM

Ok can those who think this is really important please explain why?

Aklapper added subscribers: Tamzin, Aklapper.

Unfortunately closing this Phabricator task as no further information has been provided.

@PinkAmpersand: After you have provided the information asked for in T59815#945246, please set the status of this task back to "Open" via the Add Action...Change Status dropdown. Thanks!