There is no security issue using RIGOR_FULL here, because the
information is not used to take an action. It is used for information to
the caller and the caller may not allow the action.
But even the caller allows the action, the action api code would check
permission with RIGOR_SECURE before doing the action.
Also use the constant to make clear which string is from api and which
one is from the PermissionManager
Bug: T239451
Change-Id: If182f0e967187704ba3fdd14592a0badff097571
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces calls to
Title::userCan() with the new service in API classes.
Bug: T220191
Change-Id: I768d07a520ca6473a4eefb88c9f587657bc74357
This was originally a global search and replace. I manually checked all
replacements and reverted them if (due to the lack of type hints) either
null (that would be 0 when counted) or a Countable object can end in the
variable or property in question.
Now this patch only touches places where I'm sure nothing can break.
For the sanity of the honorable reviewers this patch is exclusively touching
negated counts. You should not find a single `!== []` in this patch, that
would be a mistake.
Change-Id: I5eafd4d8fccdb53a668be8e6f25a566f9c3a0a95
T194585 raises a use case for callers to be able to know why an action
is not allowed. We can make that possible easily enough. The default
remains to return only a boolean.
This also deprecates inprop=readable in favor of intestactions=read,
since they both just return `$title->userCan( 'read', $user )`.
(ApiQueryInfoTest added by David Barratt)
Bug: T194585
Change-Id: Ib880f0605880eac776d816ea04e0c7ab9cfbaab1
Co-Authored-By: David Barratt <dbarratt@wikimedia.org>
Returns the displaytitle (if present) or title->getPrefixedText for a
page, converted for each language variant configured on the wiki.
Bug: T178446
Change-Id: I35100af3824ca65c4fe5c106d4a6fbe4e5f75046
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
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 used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
This allows for removing $wgContLang from many API modules where it was
only used to call $wgContLang->formatExpiry() in a way in which the
results don't actually depend on the language.
Change-Id: Ib0f25f288b9b87d2e4131297c552e5971696db87
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 a method for getting watchlist's notification timestamps
for a batch of LinkTargets.
Bug: T129482
Change-Id: I1f84212e7879a84b34bb3b53859069fcea282bba
This is for batch counting of visiting watchers, following the change
made in I2868c31fc09121de381d822e8f49194e3022bb42.
Query/logic has been extracted from ApiQueryInfo.
Bug: T129482
Change-Id: Ia9a534f5edb7af3cb7bf86be358dddb5d8c259cf
Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4 part of them problem
with incorrect API response but if when no watchers data is
fetched (ie. due to early return in ApiQueryInfo::getWatcherInfo),
response contains "watchers": null instead of skipping "watchers"
key entirely.
Bug: T129482
Change-Id: I9cab120ec4e6a9cf4626678e45ef14ea8efc8cbc
Fixes an issue introduced in:
I5a465773599cce9f8c9e94847cede6d12282c827
The new code now returns all targets even when 0
watcher have been found.
This patch adjusts the api to expect that.
Bug: T129482
Change-Id: Ie84e6feaa42db1bc7a1f89b56aed37dd7fe95ea4
This change introduces two new keys in the response:
* "pagelanguagehtmlcode" for the BCP 47 conform language code
* "pagelanguagedir" for the direction of the language
Example:
"pagelanguagehtmlcode": "en-GB"
"pagelanguagedir": "ltr"
The existing key "pagelanguage" contains the internal language code format:
"pagelanguage": "en-gb"
This duplication avoids reimplementing wfBCP47() and a mapping from
all language codes to the direction of the languages in JavaScript.
Bug: T117392
Change-Id: I26d033e33bfa60c8ff72ba70bb564cba4303a8b6
Whether the actions pass or not depends on the current user, including
the results of several hooks and whether the current user is blocked.
Also, we can clean up the test for public inprops slightly.
Change-Id: I7e2610dd609c52711355b640778f795520a4ff8c
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
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 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
Disabled by default, enabled with inprop=protections,
returned as 'restrictiontypes', also for non-existing titles.
Change-Id: I98604b60626b84bd8cb601a4149b80db1b6787b7
There are cases where the list of values for a 'prop' parameter may be
manipulated by a subclass or by a hook function of some sort. Rather
than requiring the subclass/hook to completely replace a monolithic i18n
message, let's add the possibility of separate messages for each value
in the list.
Bug: T77930
Change-Id: I0bb061c62ebeef125062460e26306c88390f7b31
