Last modified: 2008-10-16 15:50:31 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 14210 - Activate write API on production wikis
Activate write API on production wikis
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 14261
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-21 14:17 UTC by Carl Fürstenberg
Modified: 2008-10-16 15:50 UTC (History)
9 users (show)

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


Attachments

Description Carl Fürstenberg 2008-05-21 14:17:32 UTC
what does it take to activate it?
Comment 1 Brion Vibber 2008-05-22 18:18:41 UTC
Some favorable reports from testers trying it out on test.wikipedia would be nice.
Comment 2 Bryan Tong Minh 2008-05-23 19:03:18 UTC
My basic edit test using mwclient <http://mwclient.sourceforge.net/> works. See <http://mwclient.svn.sourceforge.net/viewvc/mwclient/tests/basic_edit_test.py?view=log> for the test routine.

This test routine contains:
* Page creation
* Old file deletion
* File deletion
* Page deletion

We need upload support I think before continuing.
Comment 3 Roan Kattouw 2008-05-23 19:11:40 UTC
(In reply to comment #2)
> We need upload support I think before continuing.

I agree that we need upload support, but I don't agree that we absolutely *need* it: we can develop it later and disable it at WMF ($wgAPIModules['upload'] = 'ApiDummy'; where ApiDummy is a class that always throws an error message) until we've tested it.

As to your script: I can't really read Python, but judging by the messages it prints it looks like it does what you said.
Comment 4 slakr 2008-05-25 17:49:49 UTC
I also think that an extra sort of check should be used to ensure data integrity.  For example, if you send the edit token early (i.e., before the payload of the actual body of the edit) and transmission of the body is interrupted for some reason, the bad edit will still get committed.  This doesn't happen in normal client edits, as most browsers send post arguments in the order in which they appear on the final rendered page, and the edit token appears after the body; so, if transmission is interrupted, the correct edit token won't be sent, and the bad edit won't be committed.

... however, when it comes to the API, most edit requests will be coming from developers who *might* stick the edit token after the payload, but could realistically make it appear anywhere.  It might be an idea to explicitly request that it be sent after the body; or, alternatively, add an extra argument that hints a crc (e.g., MD5 or SHA-1) so that if the payload doesn't match the crc, the edit is discarded with an error.  The downside to the latter method would be that non-md5/sha-1-enabled clients would be left in the dark without explicit modification to integrate the hash algorithms. 

--slakr
Comment 5 Roan Kattouw 2008-05-25 20:02:04 UTC
(In reply to comment #4)
> ... however, when it comes to the API, most edit requests will be coming from
> developers who *might* stick the edit token after the payload, but could
> realistically make it appear anywhere.
If that's the case those developers should ensure that token= is sent after text=. It's really not that hard to come up with or to implement.
Comment 6 Ilmari Karonen 2008-05-27 23:26:53 UTC
This is going off on a tangent, really, but I wonder if it wouldn't be too much trouble to require some type of checksum parameter (MD5? SHA? CRC?) in the edit API?  That would immediately catch most types of edit corruption, even things like charset issues or broken proxies that the current checks don't, and wouldn't rely on details like parameter ordering.  The downside, of course, would be that clients would have to compute the checksum, but surely any decent programming language these days has functions to compute a simple hash, right?
Comment 7 Roan Kattouw 2008-05-28 09:22:56 UTC
(In reply to comment #6)
> This is going off on a tangent, really, but I wonder if it wouldn't be too much
> trouble to require some type of checksum parameter (MD5? SHA? CRC?) in the edit
> API?  That would immediately catch most types of edit corruption, even things
> like charset issues or broken proxies that the current checks don't, and
> wouldn't rely on details like parameter ordering.  The downside, of course,
> would be that clients would have to compute the checksum, but surely any decent
> programming language these days has functions to compute a simple hash, right?
> 

Added md5 parameter in r35473
Comment 8 Carl Fürstenberg 2008-05-28 21:25:36 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > ... however, when it comes to the API, most edit requests will be coming from
> > developers who *might* stick the edit token after the payload, but could
> > realistically make it appear anywhere.
> If that's the case those developers should ensure that token= is sent after
> text=. It's really not that hard to come up with or to implement.
> 

methinks in some languages that's not trivial, as often it's not defined that the order in an associative array (hash) is maintained.
Comment 9 Roan Kattouw 2008-05-28 21:28:05 UTC
(In reply to comment #8)
> methinks in some languages that's not trivial, as often it's not defined that
> the order in an associative array (hash) is maintained.

Well at least we now have the md5 parameter (see comment #7), which should solve that issue.
Comment 10 Gurch 2008-06-14 23:41:20 UTC
Any progress on getting API editing into a sufficiently usable state for Wikimedia use? Seems that this would reduce the bandwidth demands of many bots and editing tools.
Comment 11 Max Semenik 2008-06-15 06:22:10 UTC
(In reply to comment #10)
> Any progress on getting API editing into a sufficiently usable state for
> Wikimedia use? Seems that this would reduce the bandwidth demands of many bots
> and editing tools.

It's being slowly worked upon. So far it's still very immature.
Comment 12 Siebrand Mazeland 2008-08-17 18:46:22 UTC
http://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php shows "#$wgEnableAPI = false;", which means that it is using the setting in DefaultSettings.php, which is $wgEnableAPI = true;. Not emabled for private/fishbowl wikis.

Hence: RESOLVED.
Comment 13 Siebrand Mazeland 2008-08-17 18:49:14 UTC
Comment 12 is bogus. Sorry.
Comment 14 Siebrand Mazeland 2008-08-25 23:09:30 UTC
Now really closed. Brion enabled it a 9 mins. ago and announced it on wikitech-l[1].

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2008-August/039178.html
Comment 15 MountainBlueAllah 2008-10-16 15:50:31 UTC
*** Bug 14863 has been marked as a duplicate of this bug. ***

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


Navigation
Links