New hooks:
* AddNewAccountApiForm
* AddNewAccountApiResult
These hooks are used in ConfirmEdit here: Id628def
Sample API client: https://github.com/brion/api-createaccount
Bug: 46072
Change-Id: If5b7dab80ac85dbfa0f7a54a445356783df5e914
Add checks to token-returning functions to prevent returning tokens in
jsonp mode. This affects action=tokens, action=login,
action=createaccount, and action=query&list=deletedrevs.
Also, remove the "gettoken" parameter to action=block and
action=unblock, which has been deprecated since 1.20.
Bug: 49090
Change-Id: Ibeaa5c72d8084585092b15935a3f5709104bf7f7
Currently, WatchAction::doWatch and WatchAction::doUnwatch return true
always. Let's have them return a status object instead.
This also cleans up the handling of Status objects in some of the API
modules.
Change-Id: I9dd9f0fd499c37f29fa12bcdb6142238a1f11e4d
$wgLoginLanguageSelector is related to how the interface of
special:userlogin works. It doesn't make sense to listen to it
in the api module
Also throw error if invalid lang code is specified (for sanity)
Change-Id: Ibf72fd5a318cadc450b3b579757ee8145864a27a
Certain errors (user blocked, user doesn't have permission)
were causing uncaught exceptions to be thrown in this api module.
Try to check for those cases first. Also added some errors
to the possible error list.
Change-Id: Id86984ade23a818317b942de3e9cf0ccdb43fba7
If you made a request to action=createaccount and this was
the first time (so no account creation token had yet been
generated for you) a "nocookiesfornew" error was returned.
This is incorrect, what is supposed to happen in that
case is the api returns what token to use. This is
how users are supposed to request tokens, so the
issue is very confusing.
No release notes since this module was introduced in
this version.
Also removed sessionfailure from possible errors,
as it isn't one (that status triggers the needtoken
result).
Change-Id: Ibfc3879fa89b1e11303aef65feb45a91afc215e6
Improved documentation for the parameters for action=createaccount
and fixed the help link so it is valid.
Change-Id: I8123aed59077d2cb7446df43fefbb6632dc608d7
This happens when an anonymous user wants to create an account for himself through
the API. This is due to the fact that User::addNewUserLogEntry() was always using
$wgUser as performer, but the API does not replace $wgUser by the newly created user
object when the peformer is an anonymous user.
Changed User::addNewUserLogEntry() to directly take the log action as first parameter,
rather than a boolean value saying whether the password was sent by e-mail or not,
and force the performer to be the user itself in the log action is "create". This
avoids such problems in that case, no matter the value of $wgUser, and it makes this
parameter much more readable that the old one. Backward compatibility is maintained.
Creating an user and sending its password by e-mail will still log the performer's
IP address in the log if this is made by an anonymous user.
Finally the second parameter of the AddNewAccount is now correct when creating an
account from the API, it was always false previously.
Change-Id: I188ecf420b85e9d1dab6fb933ed50d5f58532109
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
Created new API action "createaccount" that
allows access to account creation. Takes
username, password, email, realname, token,
and optionally mailpassword and reason.
Errors are given in an errors array. Note
there is no way to natively handle CAPTCHAs
as there is no uniform implementation of
presenting CAPTCHA links to user. Right now
the best an extension can do is return an
error in AbortNewAccount, which will then
be displayed as an error in the Api result.
Change-Id: Ibdb1e50d434fb857683e1e4ff5a4a5a91c6b7c3a
