$request->getHeader( 'Api-user-agent' ) was returning false,
and we can only accept string header values.
Bug: T214080
Change-Id: I3de8a455ad7dab9e3a67e24439e95f4968c93243
I would argue that these comments do not add any information that
would not be there already. Having them adds mental overhead, because
one needs to read both the comment and the next line of code first to
understand they say the exact same. I don't find this helpful, but
more distracting.
Change-Id: I39c98f25225947ebffdcc2fd8f0243e7a6c070d7
An updated spec[1] removed the User-Agent header from the list of forbidden
headers for XHR, so some clients are now requesting to use it.
[1] https://github.com/whatwg/fetch/commit/dab09b0c483
Change-Id: I43d42c3c3a6510721ff7e5fc406db797bf08ffae
The code for all uncaught exceptions will in the future be
"internal_api_error". If the client needs to know the class name for
some reason, it can check the new 'errorclass' data item on the error.
Change-Id: Ia9e32bbb8d17692203f4fbcee53a20e87be1776e
Validate them in ApiMessageTrait when the message is created, and again
in ApiMain before they're included in the header.
This also introduces an "api-warning" log channel, since "api" is too
spammy for real use, and converts a few existing things to use it.
Bug: T208926
Change-Id: Ib2d8bd4d4a5d58af76431835ba783c148de7792a
Depends-On: Iced44f2602d57eea9a2d15aee5b8c9a50092b49c
Depends-On: I5c2747f527c30ded7a614feb26f5777d901bd512
Depends-On: I9c9bd8f5309518fcbab7179fb71d209c005e5e64
ApiMain (and also api.php) tries to catch any Exception so as to provide
a properly-formatted error message to the client instead of an HTML
error page.
With PHP 7.0, some cases that produce an Exception in HHVM instead
produce an Error. The API code should catch these too.
Fortunately neither Zend PHP nor HHVM care if you try to catch a class
that doesn't exist, so we can just add catch blocks for Throwable and
not worry about it.
Bug: T202416
Change-Id: I189eee466bd09870bc172f2420be393a7c0b1900
Clarify and simplify exception output by deprecating
$wgShowSQLErrors and wgShowDBErrorBacktrace.
$wgShowExceptionDetails will now control most related output.
$wgShowHostnames will now solely control output of
MWExceptionRenderer::reportOutageHTML.
Bug: T165768
Change-Id: Idead2c11c499463dfa6293c3d4b33be3bde92e1a
The rate will be about 8k req/s, whereas currently graphite1001
receives about 350k metric updates per second, so we would expect
this to increase statsd load by about 2%.
This would have been very helpful in diagnosing API cluster overload
incidents such as the one on July 11.
Change-Id: I0a248e1bcec05915d98ec735f4cfb9800e64412d
ApiMain already caches the printer in ->mPrinter, so if
getPrinterByName() is being called more than once that's because we
really want a new printer instance, without any cached errors or other
behavior that results from reusing the same instance.
Bug: T199949
Change-Id: I779cbbaa8aab9b049a8eed732416edd828121ec4
Specifically, check the assert and assertuser parameters before setting
up the action module, so errors in parsing the module's parameters due
to being logged out don't override the client's intended "am I logged
in?" check.
Note this means that assertion failures will no longer use custom module
output formatters. This seems like an acceptable tradeoff: on Wikimedia
sites in May 2018 there were no requests that would have been affected
by this change.
Bug: T197672
Change-Id: I02a71395d5ed9f445e57162f2136292825f8dbb5
This will be useful when an extension does something expensive and wants to
make sure users don't put too much pressure on the system.
Bug: T194950
Change-Id: I8a396d07c2d5764a680d0e5536cd1f99edbe141e
With MCR coming up, ApiEditPage is going to need to be able to take
"text" and "contentmodel" parameters for each slot-role, and enumerating
such parameters for every possible slot would probably get rather
confusing as to what is required when, or at least long-winded in
repeating the exact same thing for every possible role.
So let's abstract it: we'll have an "editroles" parameter to specify which
slots are being edited, and ApiEditPage will just declare that
"text-{role}" and "contentmodel-{role}" parameters should exist for each
value of "editroles" in the submission.
Note this patch doesn't introduce anything that uses templated
parameters, just the functionality itself. For testing purposes you
might cherry pick I2d658e9a.
Bug: T174032
Change-Id: Ia19a1617b73067bfb1f0f16ccc57d471778b7361
One bug fixed: if ApiCheckCanExecute returned false but didn't set
$message, we would try to output a message of false, which would throw
an exception.
Change-Id: Ib06970e280d750ff57d81672f1b365167b93aa3e
One bug fixed: a timestamp of '00' or similar would get interpreted as
'now' by mistake instead of Unix timestamp 0, without throwing the
warning for using 0 instead of 'now'. This is because it called
wfTimestamp() once to parse the input date, got a Unix timestamp of 0
back, and then tried passing that 0 back to wfTimestamp again to
reformat as a wiki date, but it got reinterpreted as 'now'.
Also fixed parameters with type "user" to validate usernames more
correctly. This might be risky, though, if I missed any valid
usernames, or if API clients were for some reason relying on passing in
invalid usernames. If we don't actually want to do this, we should add
a comment explaining why we're allowing any title without a fragment
rather than validating properly.
Still lots more work to do here.
Change-Id: I56b4290263df8698efdbddda71a7eabd9e303abc
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
Breaks some line where the ignore is not needed.
The sniff was changed upstream to be okay
with long unbreakable lines in comments
Change-Id: I2bbe2be7cedd4d3c0ce8dc3e62d0e268bc171876
Prior to Id304010a, the API help included non-mangled anchors even when
$wgExperimentalHtmlIds was false. This was lost in Id304010a when the
new $wgFragmentMode is [ 'legacy' ], as is the default, despite the loss
being pointed out multiple times in code review.
Change-Id: Ibcb86deb4e3ea2131211f184f46960e5ad390212
For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
MWExceptionHandler::rollbackMasterChangesAndLog() only logged exceptions
if there were already master changes. This is extremely problematic when
debugging, especially in situations like DeferredUpdates where they were
silently being swallowed.
This makes it log exceptions in all paths, erring on the side of logging
the same exception twice (theoretically it's possible I suppose) instead
of not at all.
Also make the method able to handle DBError exceptions, which most of
the callers seemed to be assuming. ApiMain was handling this explicitly.
Bug: T168347
Change-Id: I8739051f824a455ba669344184c3b11ac95cb561
If it's not a preflight, it's either a simple request or an actual
request after a preflight. But simple requests can only be GET, HEAD, or
POST, and we only return a successful response for a preflight if the
actual request is going to be GET or POST. So either way it shouldn't be
handled as CORS.
This also adds a response header to indicate to the end user why
something they probably intended as a CORS request wasn't handled as
one, to help with debugging.
And it renames a local variable that confused me when looking back at
this code.
Bug: T168558
Change-Id: Ia66c74e1cc8536c6c478237540abb4d7a98b9803
ApiMain will add a header to indicate that lacksSameOriginSecurity()
forced the request to be processed as if logged out, and ApiSandbox will
detect this header to display a helpful message on the results page.
Bug: T165797
Change-Id: I56390b31563c75d83cf0a8ffb1b8e4f3283895f0
maxlag is the default mechanism most bots and libraries use in
determining when to back off due to wiki overload. However these days,
there are other things that should be considered when asking bots to
back off, one of those is job queue size.
For compatibility and simplicity of use, the number of jobs is converted
into something resembling seconds using a configurable factor. We also
output the total number of jobs in the API error output so more
sophisticated clients can do a more advanced back off.
Bug: T160003
Change-Id: Iedae2344a3d93202efbdd1bf807cef6165b6257a
Stuff like passwords and CSRF tokens shouldn't be in the logs.
The fact of being sensitive is intentionally separated from the need to
be in the POST body because, for example, the wltoken parameter to
ApiQueryWatchlist needs to be in the query string to serve its purpose
but still shouldn't be logged.
Bug: T125177
Change-Id: I1d61f4dcf792d77401ee2e2988b1afcb2a2ad58f
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I49e2a10350a328a8572fcedd44012751a29e1068
