Last modified: 2009-02-28 19:18:48 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12217 - "/dmirror/http/en.wikipedia.org/w/" added to article text
"/dmirror/http/en.wikipedia.org/w/" added to article text
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-06 03:59 UTC by Cacycle
Modified: 2009-02-28 19:18 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Cacycle 2007-12-06 03:59:16 UTC
The article text

"| location"

has been changed to

"| location = /dmirror/http/en.wikipedia.org/w/"

for several anonymous edits.

Here are example diffs:

http://en.wikipedia.org/w/index.php?title=Laver_%28seaweed%29&diff=prev&oldid=168033887
http://en.wikipedia.org/w/index.php?title=Food_safety&diff=prev&oldid=175864761
http://en.wikipedia.org/w/index.php?title=Insect_repellent&diff=176082104&oldid=173443750 (multiple edits)
Comment 1 Jesse (Pathoschild) 2007-12-06 04:04:47 UTC
This appears to be a poorly coded web proxy, not a problem with MediaWiki. Please report it at [[Wikipedia:WikiProject_on_open_proxies]].
Comment 3 Ilmari Karonen 2007-12-10 23:08:35 UTC
It _is_ a MediaWiki issue insofar as we _could_ be blocking such edits, but aren't.  We used to have a problem with "backslashing proxies" that incorrectly passed any submitted data through the PHP addslashes() function, leading to "Joe's" first becoming "Joe\'s", then, if edited again, "Joe\\\'s", etc.  However, I fixed that one with a simple hack: the edit token, which the browser must return correctly for the edit to be accepted, now contains a backslash.

In principle, we could eliminate (almost) all such errors by including the article text twice in the edit form, once normally and once in a hidden field, and checking that the version in the hidden field gets returned intact.  Of course, this would double the amount of data that would need to be transmitted in each direction, which could be an issue for large pages.  (It might also break some existing bots if the new hidden field was mandatory, but we could avoid that by leaving it optional.)  Also, one case which it wouldn't fix would be when the mangled text was entirely original, such as when starting a new page or section (with "section=new").  I can think of ways to work around that latter issue using JavaScript (URL-encode or base64-encode the text and submit it for comparison), but that's yet another layer of complexity...

One benefit from such a general fix would be that we'd also catch broken user agents that mangle Unicode characters.  Come to think of it, I might consider adding one or two Unicode characters to the edit token just for this.  However, adding "location=test" to the edit token feels somehow excessive...
Comment 4 Niklas Laxström 2009-02-28 19:18:48 UTC
There should be other methods to catch these by now.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links