Last modified: 2013-02-28 18:18:10 UTC
When uploading using [[Special:UploadWizard]] the image upload gets logged into the CheckUser log as: (Rejestr operacji) . . 22:19 . . Saper (dyskusja | edycje | zablokuj) Saper uploaded "File:Screenshot one.png" (User created page with UploadWizard) IP: 127.0.0.1 instead of (Rejestr operacji) . . 22:37 . . Saper (dyskusja | edycje | zablokuj) Saper uploaded "File:No sighted version en.png" (User created page with UploadWizard) IP: 2A01:198:200:15F:0:0:0:2 Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11 This is because after commit a31d0f8edd167e9ee301b694a8092fe0cbcfdabf (Change ID: Iae38b93d65182158561b92168af51a1e9f50374c) the actual upload is handled by the command-line utility that does not receive all WebRequest metadata. Reverting this commit has restored this functionality in my tests (even though there are multiple API requests in the log and only the final one adds the entry to the "image" table).
*** Bug 44074 has been marked as a duplicate of this bug. ***
I believe Aaron has a live hack to fix this, and will come up with a more permanent fix.
This seems to be a recurrent issue with various extensions (WikiLove, Translate in the past year), so it might be worthwhile to see if there is a common issue in the code that was initially uploaded, or the method of resolution. Might also be worthwhile to add "verify that IP address pulls through properly on Checkuser results" to new extensions prior to commit.
(In reply to comment #3) > This seems to be a recurrent issue with various extensions (WikiLove, > Translate > in the past year), so it might be worthwhile to see if there is a common > issue > in the code that was initially uploaded, or the method of resolution. Might > also be worthwhile to add "verify that IP address pulls through properly on > Checkuser results" to new extensions prior to commit. Note previous bug 34838 and bug 35136 and this is also apparently associated with LiquidThreads.
(In reply to comment #2) > I believe Aaron has a live hack to fix this, and will come up with a more > permanent fix. I think disabling it in master too is what I will do.
(In reply to comment #5) > (In reply to comment #2) > > I believe Aaron has a live hack to fix this, and will come up with a more > > permanent fix. > > I think disabling it in master too is what I will do. https://gerrit.wikimedia.org/r/#/c/44693/ Done.
(In reply to comment #3) > This seems to be a recurrent issue with various extensions (WikiLove, > Translate in the past year), so it might be worthwhile to see if there > is a common issue in the code that was initially uploaded, or the > method of resolution. Might also be worthwhile to add "verify that IP > address pulls through properly on Checkuser results" to new extensions > prior to commit. This is usually accomplished in the form unit tests, I believe.
(In reply to comment #7) > (In reply to comment #3) > > This seems to be a recurrent issue with various extensions (WikiLove, > > Translate in the past year), so it might be worthwhile to see if there > > is a common issue in the code that was initially uploaded, or the > > method of resolution. Might also be worthwhile to add "verify that IP > > address pulls through properly on Checkuser results" to new extensions > > prior to commit. > > This is usually accomplished in the form unit tests, I believe. Well, one would have thought. Unfortunately, it seems that whatever test is being used has allowed the same problem to slip through on at least three occasions that I came up with from the past year. That means the test isn't testing what it needs to test in order to ensure that we don't get this result from the code. It's a system problem, not a people problem; I have no doubt that the usual suite of tests were being done. However, we need a test that will tell us whether or not a CU will see 127.0.0.1 results instead of the actual originating IP and UA, and it appears that particular test isn't incorporated into the pre-release QA check yet. I have faith that a method for testing this, in order to ensure that this particular question is adequately answered, will be developed.
I think the solution might be to throw an exception on every case where an attempt is made to change something (let's say push a revision) where no valid WebRequest object is provided, containing User-Agent for example. Or some workaround is attempted via FauxRequest or half-baked API call.
Lowering priority since this isn't in production anymore.
https://gerrit.wikimedia.org/r/#/c/48940/
