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
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
The module's summary will be used as the description of the value.
Since these are often very long lists, this also changes ApiSandbox to
collapse <dl> lists in parameter descriptions by default.
Bug: T123930
Change-Id: I205b68a52a94cae4c1cdf7ec9fd3e8a04d565919
This has a number of implications:
* A deprecation warning is automatically generated if the value is used.
* action=paraminfo can list it in a machine-readable manner.
* It is automatically flagged in the help when message-per-value mode is
used.
* In values lists in the help, it's specially marked (currently
strike-through).
* ApiSandbox will mark it in the widgets (currently strike-through).
Deprecation of submodules is not automatically detected here, that's
left for a later patch.
Bug: T123931
Change-Id: Idad6377063e457f9352a99df5c7cc15b1563579e
To fix T123930, it would be very handy to have the summary for each
module without any of the additional explanatory text.
Bug: T166411
Change-Id: I778bab2b87971875aed4c804341ad59c1c6e021f
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
This was suggested at a Developer Summit session as a way to get people
to know about the mailing list.
This also adds a hook so ApiFeatureUsage can mention itself in
deprecation warnings too.
Bug: T148855
Change-Id: I04a7cf89e87e48f6504803dd173e779017a205d0
Log events are sometimes attributed to a special page; it should be
allowed to use rcnamespace or lenamespace to filter for these.
It's also possible for special pages to be the targets of redirects, so
list=allredirects and prop=redirects should find them.
Maybe someday we'll record links to and transclusions of special pages
too (see T19597), so we may as well make it possible to query for those
as well via list=alllinks, list=alltransclusions, list=backlinks,
list=embeddedin, prop=linkshere, prop=transcludedin, prop=links, and
prop=templates.
NS_MEDIA has similar considerations: although we currently "normalize"
page links to the corresponding File and I don't think anything logs the
Media title rather than the File, transclusions and redirects do show
up in those tables.
Bug: T154319
Change-Id: I00348f83855c6c703b6bd6015f6d3bedc5bfd1c5
Blocks made for configured proxies, dnsbls, or the configured range
soft-blocks being added in I6c11a6b9 aren't real blocks stored in the
database. Let's actually flag these blocks as such and use a more
appropriate message when displaying them to the user.
Change-Id: I697e3eec2520792e98c193200c2b1c28c35bf382
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
We already throw around some exceptions that are localized
(ErrorPageError and its subclasses, MalformedTitleException), but
there's no standard way to recognize them. Let's change that.
Then let's use them in the API to be able to have internationalized
errors when such exceptions are caught, instead of wrapping the
English-language version.
Change-Id: Iac7c90f92a889f8de9dae373547c07b884addaea
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
Adds support for specifying an asterisk '*' instead of a pipe seperated list
of all the allowed options for a multi-option param.
Adds a line to the api help for these parameters.
Adds a "allspecifier" key to ApiParamInfo parameter responses
Enables the default ('*') for parameters of type 'namespace'.
Bug: T124009
Change-Id: I3905bb2516dc1ff982f1beeac3deed6b69446a77
All deprecated ApiResult methods are removed. These have been deprecated
since 1.24 or 1.25, and the only users remaining in Gerrit are wrapped
in backwards-compatibility checks and so should not be being called.
ApiBase, ApiFormatBase, ApiMain, and ApiQuery methods for generating the
pre-Ib14c00df help text are removed. Nothing has called these for a long
time, and only Flow implemented them in any way. Deprecated methods for
providing the text for such help, such as getDescription(), haven't been
removed yet, though, since some extensions still call some of them.
Change-Id: I3ca7c98174b4a3f6f67f2b023e0f4446637e7a84
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
If a client submits data that is not NFC-normalized Unicode or that
contains C0 controls other than HT, LF, and CR, it gets normalized before
the API ever sees it. Which can lead to difficult-to-handle bugs when,
for example, a title is subject to normalization so the client can't
find the specific title it submitted anywhere in the response (T139130).
This patch does two things:
* Detects when normalization was applied to an input value (at the
MediaWiki level, anyway; if PHP or earlier does it we're just out of
luck) and add a warning to that effect.
* For ApiPageSet's 'titles' parameter, split into the individual titles
and add them to the 'normalized' list in the response. This requires
encoding the pre-normalized strings to avoid ApiResult's own
normalization.
Bug: T29849
Bug: T144071
Change-Id: I215fd3edd7a5e1b45292e60768bf6dd5ad7f34de
When a multi-valued parameter's value begins with U+001F, the values
will be split on that character instead of pipes. This will be useful
for things such as action=options&change= or meta=allmessages&amargs=.
Since MediaWiki doesn't otherwise accept C0 control characters
(WebRequest::getVal() replaces them with �), there's no possibility that
this will conflict with a literal use of U+001F.
Special:ApiSandbox and mw.Api are updated to make use of this, with the
latter having an option to disable the behavior in case something is
depending on [ 'foo', 'bar|baz' ] turning into 'foo|bar|baz'.
Pipe is still used as the separator when the value doesn't begin with
U+001F, and will be forever since it's generally more human-friendly and
is needed for backwards compatibility with basically every API client in
existence. The requirement that the value begin with U+001F, rather than
simply contain U+001F, is to avoid clients having to somehow
special-case "param=foo|bar" where that's intended to be a single value
"foo|bar" rather than two values "foo" and "bar".
Bug: T141960
Change-Id: I45f69997667b48887a2b67e93906364a652ace5a
Currently the API just throws away the excess values, no continuation.
This is probably not the best behavior. There is a warning, but clients
are notorious for just ignoring warnings.
We could improve the situation:
* Turn it into an error.
* Turn it into an error for most cases, but allow some to override if
necessary.
* Allow some cases to make it an error, while keeping it a warning by
default.
Before we can decide which option to pick, we should get an idea of how
often this is being hit and which things it's being hit for.
Bug: T41936
Change-Id: I52926f410c30d1cd7e7fcd86465b16519fb5cbd2
Passwords should always be submitted in the POST body, not in the query
string. Thus, a warning will now be returned if the password for
action=login or any sensitive authentication request parameters for
AuthManager actions are found in the query string.
These warnings should be upgraded to errors in 1.29.
Change-Id: Ifb2c684bb28c9acc004be2b0c2fef839eb7624aa
This function takes the class file path, and iterates up through its
parent directories until it hits either a registered extension, or $IP
(for core) or $IP/extensions (for an unknown extension). This change
adds $wgExtensionDirectory as another iteration stopper, so that
unregistered extensions in $wgExtensionDirectory will not cause
iteration back up to the filesystem root, or to $IP if
$wgExtensionDirectory is a child of $IP other than $IP/extensions.
Change-Id: I06553591b0b6156e945aad5176479eb71517e77d
Instead of constructing a new Message from the Message as
a MessageSpecifier, just clone the existing Message which will preserve
subclass data.
Also, make use of this to simplify the logic in ApiBase::parseMsg().
Change-Id: I9545acb8da752c0c21e16d8b1d37d8802fcb329d
The header is intended for use with XMLHttpRequest when the request
might be part of an XSS. The hook is for extensions that might need to
add additional checks of some sort.
Bug: T98313
Change-Id: I0e5f2d3b29a79a12461dc33c90c812a56810f536
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
When the code was written, $status->getErrorsArray() would return the
Message objects unchanged. But I0deaa988 broke that and apparently
didn't bother fixing callers.
Now that I'm trying to actually use it for something, I find it's
broken, so I fixed it.
Change-Id: I763729c5bdd63448b50229774ef1f9d12cfb795d
Th API handles parameters of type 'user' as page titles, which resulted
in silently dropping # characters and anything following them.
Reject such usernames explicitly instead.
Bug: T132852
Change-Id: Iba8061b20d5e25de80ff30d09eb53939c97cdaac
* ApiBase::addTokenProperties() was removed (deprecated since 1.24).
* ApiBase::getFinalPossibleErrors() was removed (deprecated since 1.24).
* ApiBase::getFinalResultProperties() was removed (deprecated since 1.24).
* ApiBase::getRequireAtLeastOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getPossibleErrors() was removed (deprecated since 1.24).
* ApiBase::getRequireMaxOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getRequireOnlyOneParameterErrorMessages() was removed (deprecated since 1.24).
* ApiBase::getResultProperties() was removed (deprecated since 1.24).
* ApiBase::getTitleOrPageIdErrorMessage() was removed (deprecated since 1.24).
* ApiBase::parseErrors() was removed (deprecated since 1.24).
* Remove related constants ApiBase::PROP_ROOT, ApiBase::PROP_LIST,
ApiBase::PROP_TYPE, ApiBase::PROP_NULLABLE.
Patches were submitted for remaining uses in Gerrit extensions.
Change-Id: Idea70300874258fbcb9deef6504eb55f2ebe8d6c
