$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
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
OAuth was going to return different values for UserIsEveryoneAllowed
depending on whether OAuth headers were provided, so the bolding on
Special:SpecialPages wouldn't be odd. That wasn't liked, so instead
we'll only mark special pages as restricted based on $wgGroupPermissions
and not what extensions might do.
Also, it was suggested that if an extension can remove 'read' then the
cache headers set by RawAction and the API should reflect that.
Change-Id: I381553e79c5320083c6d6d9ddd5bc0b146600f9e
User::groupHasPermission is used for various purposes, from checking
whether it makes sense to show a "hide logged-in users" on
Special:NewPages to showing different error messages in some places when
'user' or 'autoconfirmed' is allowed the action to avoiding unstubbing
$wgUser to check $wgUser->isAllowed( 'read' ) in the common case where
'read' permission is granted to everyone.
For the OAuth work, we need to be able to catch that last type of use
without interfering with the others. This change introduces
User::isEveryoneAllowed() to be used for that type of check, which both
makes sure the right granted to '*' isn't revoked from any group and
calls a hook to allow extensions to indicate that they might remove the
right.
Change-Id: Idfee1b4d0613aaf52e143164acd6022459415c49
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
When making CORS pre-flight requests, the origin parameter must still be
included. This means that it cannot be in the POST body, as that is not
sent for pre-flight.
Document that.
Change-Id: I3fc809cf2e4ca9c2566f62d32f96d24377c72863
