After 4 months, the APIedit branch [1] I've been maintaining is pretty much finished. The branch adds the following functions to the API:
* State-changing actions ** Blocking and unblocking users (ApiBlock.php and ApiUnblock.php) ** Adding users to and removing them from groups (ApiChangeRights.php) ** Deleting and undeleting pages (ApiDelete.php and ApiUndelete.php) ** Moving pages (ApiMove.php) ** Protecting and unprotecting pages (ApiProtect.php) ** Rolling back edits (identical to the rollback link) (ApiRollback.php) * Lists ** List all blocks (ApiQueryBlocks.php) ** List deleted revisions (ApiQueryDeletedrevs.php)
All these modules (except ApiQueryBlocks) require sysop or bureaucrat rights, which means the user must be logged in through either a cookie or the lg* parameters obtained from action=login. Additionally, all state-changing actions require an edit token to be obtained from prop=info, which changes at every login (changerights tokens also depend on the username, rollback tokens on username and page name). This prevents malicious pages from tricking a logged-in sysop into clicking a link to something like api.php?action=delete&title=Very_important_page .
In order to facilitate these new modules, some minor and some less minor changes to Article.php, Title.php, SpecialUndelete.php, SpecialBlockip.php, SpecialIpblocklist.php and SpecialUserrights.php are necessary. These changes mostly involve separating UI and DB logic. For instance, instead of calling OutputPage::showErrorPage(), functions will return an error code that is interpreted by either a UI wrapper (which calls OutputPage::showErrorPage()) or an API wrapper (which calls ApiBase::dieUsage()). This means I'll just be moving code around, not changing it, except in Article::delete() (partial rewrite of the deletion generation code which was ugly as hell; it even says so itself) and Title::moveTo() (adding the possibility of not recreating a redirect). Changes will have "APIEDIT BRANCH MERGE:" in the commit reason, and will be made every two or three days. Please discuss them on this list (wikitech-l).
I welcome your criticism,
Roan Kattouw (AKA Catrope on SVN)
[1] http://svn.wikimedia.org/viewvc/mediawiki/branches/apiedit/
Bah, I still have to merge all this revisiondelete stuff. I hope it won't interfere too much, I'm tired of manually merging :/ ...
Roan Kattouw wrote:
After 4 months, the APIedit branch [1] I've been maintaining is pretty much finished. The branch adds the following functions to the API:
- State-changing actions
** Blocking and unblocking users (ApiBlock.php and ApiUnblock.php) ** Adding users to and removing them from groups (ApiChangeRights.php) ** Deleting and undeleting pages (ApiDelete.php and ApiUndelete.php) ** Moving pages (ApiMove.php) ** Protecting and unprotecting pages (ApiProtect.php) ** Rolling back edits (identical to the rollback link) (ApiRollback.php)
- Lists
** List all blocks (ApiQueryBlocks.php) ** List deleted revisions (ApiQueryDeletedrevs.php)
All these modules (except ApiQueryBlocks) require sysop or bureaucrat rights, which means the user must be logged in through either a cookie or the lg* parameters obtained from action=login. Additionally, all state-changing actions require an edit token to be obtained from prop=info, which changes at every login (changerights tokens also depend on the username, rollback tokens on username and page name). This prevents malicious pages from tricking a logged-in sysop into clicking a link to something like api.php?action=delete&title=Very_important_page .
In order to facilitate these new modules, some minor and some less minor changes to Article.php, Title.php, SpecialUndelete.php, SpecialBlockip.php, SpecialIpblocklist.php and SpecialUserrights.php are necessary. These changes mostly involve separating UI and DB logic. For instance, instead of calling OutputPage::showErrorPage(), functions will return an error code that is interpreted by either a UI wrapper (which calls OutputPage::showErrorPage()) or an API wrapper (which calls ApiBase::dieUsage()). This means I'll just be moving code around, not changing it, except in Article::delete() (partial rewrite of the deletion generation code which was ugly as hell; it even says so itself) and Title::moveTo() (adding the possibility of not recreating a redirect). Changes will have "APIEDIT BRANCH MERGE:" in the commit reason, and will be made every two or three days. Please discuss them on this list (wikitech-l).
I welcome your criticism,
Roan Kattouw (AKA Catrope on SVN)
[1] http://svn.wikimedia.org/viewvc/mediawiki/branches/apiedit/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Voice of All wrote:
Bah, I still have to merge all this revisiondelete stuff. I hope it won't interfere too much, I'm tired of manually merging :/ ...
Which classes and which functions are you gonna change most then?
VasilievVV wrote:
I think we should test this API better, e.g. create test implementation, etc.
I've informed [1] Daniel Cannon (AKA AmiDaniel) that these merges are going to happen and that we'll need a testing framework for these new modules as well. Note that only about half of current API modules have a testing framework, written by Daniel.
Roan Kattouw
[1] http://en.wikipedia.org/wiki/User_talk:AmiDaniel#New_API_modules
Roan Kattouw writes:
After 4 months, the APIedit branch [1] I've been maintaining is pretty much finished. The branch adds the following functions to the API:
- State-changing actions
** Blocking and unblocking users (ApiBlock.php and ApiUnblock.php) ** Adding users to and removing them from groups (ApiChangeRights.php) ** Deleting and undeleting pages (ApiDelete.php and ApiUndelete.php) ** Moving pages (ApiMove.php) ** Protecting and unprotecting pages (ApiProtect.php) ** Rolling back edits (identical to the rollback link) (ApiRollback.php)
- Lists
** List all blocks (ApiQueryBlocks.php) ** List deleted revisions (ApiQueryDeletedrevs.php)
All these modules (except ApiQueryBlocks) require sysop or bureaucrat rights, which means the user must be logged in through either a cookie or the lg* parameters obtained from action=login. Additionally, all state-changing actions require an edit token to be obtained from prop=info, which changes at every login (changerights tokens also depend on the username, rollback tokens on username and page name). This prevents malicious pages from tricking a logged-in sysop into clicking a link to something like api.php?action=delete&title=Very_important_page .
In order to facilitate these new modules, some minor and some less minor changes to Article.php, Title.php, SpecialUndelete.php, SpecialBlockip.php, SpecialIpblocklist.php and SpecialUserrights.php are necessary. These changes mostly involve separating UI and DB logic. For instance, instead of calling OutputPage::showErrorPage(), functions will return an error code that is interpreted by either a UI wrapper (which calls OutputPage::showErrorPage()) or an API wrapper (which calls ApiBase::dieUsage()). This means I'll just be moving code around, not changing it, except in Article::delete() (partial rewrite of the deletion generation code which was ugly as hell; it even says so itself) and Title::moveTo() (adding the possibility of not recreating a redirect). Changes will have "APIEDIT BRANCH MERGE:" in the commit reason, and will be made every two or three days. Please discuss them on this list (wikitech-l).
I welcome your criticism,
Roan Kattouw (AKA Catrope on SVN)
[1] http://svn.wikimedia.org/viewvc/mediawiki/branches/apiedit/
I think we should test this API better, e.g. create test implementation, etc. -- VasilievVV
wikitech-l@lists.wikimedia.org