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
One of the causes (if not the cause) of bug 56269 is if something
manages to throw an exception that makes it to MediaWiki::run's
last-resort exception catcher while having an open database transaction:
the transaction never gets committed or rolled back, so it gets
implicitly rolled back and a warning is raised.
The API has the opposite problem in bug 63145: it catches the exception
but then does the normal DB shutdown which *commits* the transaction.
This is certainly the Wrong Thing to do.
Ideally, neither of these would ever happen because any code using
transactions would have its own try-catch that would catch any
exception, rollback the transaction, and then rethrow the exception. But
it happens anyway, so let's have both of these last-resort exception
handlers do the rollback, and also log the exception so the throwing
code has a better chance of being properly fixed.
Bug: 56269
Bug: 63145
Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
ApiFormatFeedWrapper, for example, has nothing particularly useful to do
when given an API error to print. So allow for punting errors to the
default formatter instead.
Bug: 63150
Change-Id: Ifc034d4c7861905e382c42dc22585f0cd2beaf3f
* Moved ApiRunJobs to a special page instead of going through
ApiMain and having to fight the logic there. As a separate
internal API, this does not show up on the API help page and
is no longer effected by $wgEnableAPI.
bug: 62233
Change-Id: I1db6f526d02e130a66ee03289858a734d89e6c00
The immediate impetus behind this change is this series of events:
1. CirrusSearch hooks ApiBeforeMain to handle some setup that requires
the User object.
2. So User is loaded from the session.
3. OAuth checks the headers as part of loading User.
4. OAuth sees that the headers are invalid, and since it was called from
the API it throws a UsageException, expecting the API to catch it and
return an appropriate response to the client.
5. But nothing does so, leading to an unhelpful "Internal Error" page
being returned to the client.
We can do better than that.
Bug: 62312
Change-Id: Ib5735661eec6ebe57eaa69c67b399e703cc90fc4
I should have done it at the beginning instead of trying to
extract it from recent changes.
Same for SpecialRecentChanges and SpecialRecentChangesLinked
(subclasses).
Created a new API module for it: ApiFeedRecentChanges.
It's somewhat un-API-like and hackish, but all feed modules are.
Old URLs redirect to new ones, so this should be fully
backwards-compatible assuming sane feed reader clients.
Change-Id: I06ee0f01d896bc66545a1800b24693ce7524e433
They just end up being used for direct support requests that should
really be done on public mailing lists etc
Change-Id: If704ec8dff5fc4669165b580290cc29cf953a25b
* A background internal HTTP request used to load the API.
This handles job execution and related periodic tasks.
It avoids blocking the main request or breaking it on fatals.
* This method avoids problems that shelling could have:
** Mismatched apache/cli PHP config or versions.
** Had to start a new process and could not use opcode cache.
** safe_mode and open_basedir restrictions required a fallback.
** Some wiki farms may not respect the --wiki parameter.
** wgMaxShellMemory applies to spawned PHP processes.
** Spawning processes is more prone to DOS due to a lack
of proper limiting/pooling.
bug: 60208
bug: 60210
bug: 60698
bug: 60844
Change-Id: I78b0e709301ac4a0c7b7ed337d6969d7546674bf
Add action=revisiondelete to the API, and some functions to the
revisiondelete backend to support this.
Bug: 23005
Change-Id: Iee146fed648603b86a35927518f850771fc69bd2
- The parameter is now a string, making is more understandable than
boolean values
- It takes the same values in both wfDebug() and wfDebugLog() (except
for 'private' which is only used in the latter)
- This adds a new possibility to wfDebugLog() to log the message either
on the specific log or the general one, but not to the debug toolbar
- Old boolean values are still recognised for backward compatibility
- Also send the messages passed to wfDebugLog() to the debug toolbar
when they are written to a specific log and not restricted to logs
- Updated the calls of and wfDebug() and wfDebugLog() with the last
parameter to change it into a string
- Renamed MWDebug::sendWarning() to MWDebug::sendMessage() and added
$group parameter to it; will not break anything since that method
is marked as private
- Changed the call to wfDebug() from MWDebug::sendMessage() to use
wfDebugLog() with 'log' as thrid parameter, so that those messages
can be logged separately from the main log and they don't show up
a second time on the "debug log" tab of the debug toolbar
Change-Id: I1be09d4c1d3408ed5b26a5db02691c17c0ec0926
Added &assert=user and &assert=bot for all API modules.
Some functionality was dropped:
* assert='exists': the edit API already has &nocreate/&createonly
* nassert parameter: there is no usecase for checking that your
account is logged out or not flagged
* assert=true/false: If you want to test a failing assertion, log out
* assert=test: Not useful
* Checking edits via index.php
The error format was changed from:
{"edit": {"assert": "bot", "result": "Failure"}}
to the standard format of API errors in an 'errors' array
using the codes: 'assertuserfailed' and 'assertbotfailed'.
Bug: 27841
Bug: 53106
Change-Id: Ia4815168548fea3dbf1c305792a451374f2a3b7e
The API currently allows for adding action modules with
$wgAPIModules and query modules with various other $wgAPI*Modules
variables. But there's no way to add a formatting module from an
extension. For parallelism, let's add $wgAPIFormatModules to do just
that.
Bug: 57637
Change-Id: Ia0bd253104a4b5bc56d4fe0dc6736e2129b126f3
Fixed a little documentation issue, removed a line of unreachable code
and fixed up two formatting issues in the process.
Change-Id: If29391ee1a0daf19973437f36c3216b8716debd0
Most code replaced wasn't exactly like what logException does
but most probably should be.
A few implementation differences with the code it replaced in
various places:
* MWException if-guards
Was there only to prevent a crash because getLogMessage is an
MWException method. Now that logException is generic, it seems
sensible to start logging those as well (follows-up a97f3550a0).
* Exception::getTraceAsString
Now using MWExceptionHandler::formatRedactedTrace instead.
It wasn't using it because that method didn't exist yet.
Notes:
* DatabaseError::getLogMessage
Removed as this override was no longer doing anything (we're using
MWExceptionHandler::getLogMessage instead of $e->getLogMessage).
Introduced isLoggable() to take over the responsibility of indicating
when an exception should not be logged (follows-up bcb9f9e1c0).
* DeferredUpdates and Wiki.php
Both specificy MWException. Though ApiMain intends to catch all
and only logged MWException because it couldn't otherwise, these
actually only catch MWException (as opposed to catching all and
having an if-statement inside). Left those as-is to have them
continue propagate other exceptions.
* JobQueueFederated and JobQueueGroup
All specify to catch JobQueueError only.
Not sure whether it should catch other exceptions. It now can,
but I'll leave it as is in case it intends to have those be
handled elsewhere (or fatal).
Change-Id: I4578a0fe7d95a080f1a3b292ce7ae73a4d5fcaca
