* Convert existing use of WebResponse::header() for HTTP status headers
to use this new statusHeader() method.
* Extend unit test forFauxResponse.
I'm not calling HttpStatus::header directly in code. We keep the abstraction
layer of WebResponse so that responses can continue to be mocked/fauxed without
affecting the outer HTTP response.
Change-Id: I8a536e16659fa88b54cffa1457efb889efa5fcd6
Try falling back to use the printer without any of its parameters in
case one of them is what's failing.
Change-Id: I2611550109de4219bf1cc43333d038753e9eb87c
Two things here:
* Identify the parameter types when they're not simple strings (or
already identified).
* Add a section to the 'main' module documentation that describes
booleans and timestamp formats.
Bug: T93982
Bug: T47652
Change-Id: I67da4f4c026616eed5669256b208b03350e756c0
You can add tags at the same time as performing action=edit, as long as you
have the "applychangetags" right. Also, you can add or remove tags after
the fact from revisions and log entries using the API action=tags.
No UI is provided for either of these changes. The target audience is user
scripts, gadgets and similar tools.
Includes a new log parameter format type: "list", for a comma-separated
list of values.
Logging of change tag events is limited to those that do not accompany an
edit (i.e. those done after the fact), and is hidden from Special:Log by
default, similar to the patrol log.
Bug: T20670
Change-Id: I37275e0f73fa3127f55da0c320b892551b61ee80
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
The profileIn/profileOut pair should be covered by the Xhprof profiling
of the method calls it was wrapping.
The profileDBIn/profileDBOut pair are covered by profiling done by the
Database class.
Nothing in extensions in Gerrit is calling anything besides the
profileIn/profileOut pair (and likely those are only to avoid core
formerly throwing exceptions from internal profileDBIn/profileDBOut
calls), and nothing in core or extensions-in-Gerrit is using the methods
for fetching profiling data.
The methods are left as stubs for now to allow for backwards
compatibility in extensions.
Change-Id: I05ba4e2762dc86d5e2bafc183dce701239b43f5c
By default we send "private, must-revalidate, max-age=0" for regular
logged-in wiki viewing. This changes API responses to match.
Later, someone should update the Cache-Control header generation so
that it works the same for API responses as it does for OutputPage.
This is becoming more important since we're using the API instead of
OutputPage for editing with VisualEditor.
Bug: T74480
Change-Id: Ib309df8568de2c7137b6d13b9ca4004150a772dd
Needed to conditionally register API modules. The previous way, messing with globals
from extension functions, is getting problematic because Config class will make this
impossible.
Change-Id: I86b40aeec555dd6b3cd82cab31d96e85fdf0a665
The RESTBase team has requested the ability to check the validity of a
CSRF token and to interface with Title::userCan().
The former is accomplished by the new action=checktoken module. The
latter by a new parameter ('testactions') to the existing prop=info.
Bug: T88010
Change-Id: I2530f1315ec93f5be9fb437137992150fdc305f2
This allows users with the `managechangetags` right to create tags for
use by wiki users. (Currently there is no way for editors to apply tags
to their edits; that's to come in a later patch.)
Extensions can reserve tag names for their own use, even if they do not
define them or mark them as active.
Tag managers can also delete tags with <= 5000 uses. Currently, if a tag is
misspelt ("vandlaism") or no longer wanted (testing of OAuth, etc), the
wiki is stuck with it forever. This change allows users with the
"managechangetags" right to delete change tags from the database,
including removing them from all revisions to which they are applied.
Obviously this is a powerful thing to be able to do, but I view change
tags as a "light" kind of interface, useful for revision patrolling and
spam/vandalism fighting but not something that necessarily needs to hang
around forever. It's not a big deal for this kind of data to be thrown
away without being archived anywhere.
Tags defined by an extension can only be deleted if the extension allows
it.
Changes to tags are logged in the new "tag management" log. There's even
a nice API module, just for fun.
Bug: T20670
Change-Id: I77f476c8d0f32c80f720aa2c5e66869c81faa282
It's fairly common that the API doesn't need to load the user
preferences, except to implement the unfortunate default uselang=user.
So let's move the handling of uselang=user to
RequestContext::getLanguage(), and have the API just assume that its
parent context will eventually fall back to that for uselang=user.
Bug: T85635
Change-Id: I947348d87b31808d331055dac6feb0cc2e1dd15d
- Split out responses of preflight and actual CORS requests
- If the request is not CORS valid, don't set the CORS response headers
Note that invalid CORS requests should not actually throw error
responses, the client should simply not handle the response because the
response does not have the right headers (it's a client side policy
error not an http error). We do throw a 403 for a mismatch with the
queryparam, but since that is 'outside' of the spec, that might be
appropriate.
Bug: T76701
Change-Id: Ib296c68babe5c0b380268ee7793b3d6d35b9c3e3
The existing response seems to be designed to look good with
format=xmlfm, which doesn't make much sense now that format=jsonfm is
the default.
Change-Id: Ic3993aaf7e401d6233bbbe4522e77004099e3c40
For internal api error it is helpful for reporting when having the log
id under the exception was logged in the exception log.
Also use the redacted trace in the api error response instead of the
normal one to avoid leakage of function values if exception details are shown.
Change-Id: I7d917e532da1b1c7979a6599425f07d2f4f35aed
* This lets edits be prepared while users enter edit summaries.
* The edit form will now make use of this API, controlled by
$wgAjaxEditStash.
Change-Id: I4f4057bc0d1d4a66a8f7cfb7cdc26d443a8eb0c4
XMLHttpRequest does not allow overriding the "User-Agent" header. To
allow such clients to make effective use of the api-feature-usage log,
let's give them a different header they can use.
Change-Id: Ia1e4f52f35f8d9a8e9f5590a00854d14c11f7cc9
After consultation, it is thought that the reduced cacheability won't be
an issue.
This also adds "uselang=content" as an option since it's no longer the
default.
Change-Id: Idc24bfc8bff7392c2047a6b856760ad26a4e9800
- Changed spaces to tabs for indentation
- space after 'function'/'if'
- Added/Removed space after parenthesis/brackets/end of line
- Removed space after cast
Change-Id: I0e8e6a19b84b5e1308b632a0266cb78f688494ee
If the User language is accessed from ApiMain::__construct on a request
via OAuth and the authorization headers weren't valid, the
UsageException was not being handled.
Further, the code setting $wgLang in that constructor should be using
the language just set on the local context, not the main request
context.
Bug: 72384
Change-Id: I90900dc4a8aea22c67c0c05b38128d5dbb044f07
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
The syntax highlighting applied to the XML format is not all that great,
and applying it to other formats is just wrong. Instead of doing it
ourselves, let's just add a hook and let Extension:SyntaxHighlight_GeSHi
do it for us.
But for that to work, we have to add RL support to the pretty-printed
output, which means OutputPage. At the same time, lets internationalize
the header.
Bug: 65403
Change-Id: I04b1a3842abdf1fb360c54aa7164fc7cd2e50f4b
The existing API help, formatted as basically a plain-text document
embedded in XML and with a little bolding and a few links
syntax-highlighted in after the fact, works ok for experienced programmers
but isn't at all newbie-friendly. Further, all the help is hard-coded in
English, which isn't very friendly to non-English speakers.
So let's rewrite it. The help text is now obtained from i18n messages
and output in HTML, with the default display consisting of help for a
single module with links to help for other modules. This, of course,
necessitates deprecating many of the existing help-related methods and
hooks and replacing them with new ones, but backwards compatibility is
maintained for almost everything.
At the same time, action=paraminfo also needs to support the
'description' and other help-related fields being output in wikitext or
HTML, and I11cb063d (to access all modules via the 'modules' parameter
instead of having 'modules', 'formatmodules', 'querymodules', and so on)
is folded in.
And we also add Special:ApiHelp. When directly accessed, it simply
redirects to api.php with appropriate parameters. But it's also
transcludable to allow up-to-date API help text to be included within
the on-wiki documentation.
Note this patch doesn't actually add i18n messages for any API modules
besides ApiMain and ApiHelp. That will come in a followup patch, but for
the moment the backwards-compatibility code handles them nicely.
While we're messing with the documentation, we may as well add the
"internal" flag requested in bug 62905 (although the 'includeinternal'
parameter it also requests doesn't make much sense anymore) and a
"deprecated" flag that's needed by several modules now.
Bug: 30936
Bug: 38126
Bug: 42343
Bug: 45641
Bug: 62905
Bug: 63211
Change-Id: Ib14c00df06d85c2f6364d83b2b10ce34c7f513cc
$wgDebugAPI is supposed to be a way to quickly (and insecurely) test API
modules using GET where they'd normally require POST. But this purpose
is defeated if token handling still throws mustposttoken.
Change-Id: Iee2fb76da86bf0670f9816f24f68c611fa0728b1
New api is called "ClearHasMsg" and does nothing but erase a new message
flag from currently logged in user.
This is useful for tools that can read the new messages using some api, or some
other way (loading the text using different session, preload the text using a
buffer where it's unrevealed later if user actually did read it, or closed the
application before), so it can be useful in situations when you need to flag new
messages as read in a different time than that when you actually read them.
Bug: 64238
Change-Id: Ife575711c32bb8e3bcac789de4a6b37e1888d032
The current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
This allows action=paraminfo to indicate when a parameter is specifying
a submodule (so clients can detect what the submodule names are). This
will also allow the future action=help HTMLization to easily auto-link
to submodule docs, and will allow ApiSandbox to handle submodules more
generically.
For BC, rather than directly specifying "type": "submodule", it lists
the names of all the submodules as the type and adds an additional
"submodules" indicator on the param info object.
Change-Id: Id31babdc81d970ac781ec11daa3cdafef18ecd5d
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
This way we no longer need to disable size checking just for one operation
(enable|disable)SizeCheck functions were depricated.
Overall, this is a much better practice than disabling than re-enabling
the flag, as it might lead to accidentally forgetting to re-enable it,
just like the issue with the dangling file handlers, etc.
Example:
disable, do some complex logic, re-enable. And later, by accident,
the complex logic is changed to return a value half-way, or throws
an exception that gets handled as part of normal operations. This
results in the unsafe disabled state of the result object,
which is not good (tm).
Change-Id: I389a334d35f52f23a1847aca4aef5e96b262f589
Put Brad Jorsch (anomie) as lead developer (as he's the one
who does most of the review work etc. these days).
Made Yuri's lead developer time frame end in 2013 (as he
last commited to the api in 2013 AFAIS).
Change-Id: I640ddf251340214b4520d3072e22dfe6b54815fb
In I1b7396ceb, we were trying to log failures to Special:Log, but
since $this->dieUsage throws an exception, the log entry insertion
was being rolled back.
This is similar to I36cd645d which was for index.php calls.
Change-Id: I136ba66d2f939fcdd0c9326e04d686a30449bf4c
Follows-Up: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
The API takes multi-valued parameters as key=value1|value2|value3, not
key[]=value1&key[]=value2&key[]=value3, in part because the latter is
overly verbose when the API encourages use of large arrays.
But when someone, not knowing this, does accidentally use the verbose
syntax, they should get a warning instead of having the parameter be
silently ignored.
Bug: 64057
Change-Id: I32a16efb8028d7f6d120d20dfc886f08ed9ec97d
