Following I8a9f1f061ac69bf5abc40feccb0771a36f51bd95, core no longer
needs to know about CentralAuth and its limitations, and it doesn't need
to account for this class being extended (which is not stable to do).
Bug: T259960
Change-Id: Ia676a1f1194212e2984741e335d6cf8c8552a35a
The value is treated as a string in the current code, and while
User has an implicit __toString(), UserIdentity doesn't
Bug: T288311
Change-Id: Ibd4ff99ea034e47a038a2b57dbe84c7fb3917cb6
Expose info about user blocks from Authority. This allows calling code
to provide more detailed information to the user about why they are
denied some action on the wiki.
Bug: T271494
Change-Id: Ia84e469888866d72752aad355292666c31e12bad
Replaces calls directly to PermissionManager with calls to
the Authority object available from Context or the
GroupPermissionLookup service.
This patch does not address use of PermissionManager for
blocks.
Deprecations:
- ApiBase::checkUserRightsAny deprecated passing optional
User parameter
- ApiBase::checkTitleUserPermissions deprecated passing
LinkTarget as first parameter, takes PageIdentity instead
Bug: T271462
Bug: T271854
Change-Id: I5d7cac1c28a37e074750c46cda03283980a07fca
This brings significant modularization to the Action API's parameter
validation, and allows the Action API and MW REST API to share
validation code.
Note there are several changes in this patch that may affect other code;
see the entries in RELEASE-NOTES-1.35 for details.
Bug: T142080
Bug: T232672
Bug: T21195
Bug: T34675
Bug: T154774
Change-Id: I1462edc1701278760fa695308007006868b249fc
Depends-On: I10011be060fe6d27c7527312ad41218786b3f40d
This makes searching for them easier and makes their
order less arbitrary, especially when they are localized.
Replace one sort function wrongly chosen by me.
Change-Id: I231f28656333c5bf846bedfedb6ba5040a09f74e
If a user has partial access to modify user rights, their partial access should
not be blocked because of a partial block.
Bug: T228534
Change-Id: I7479953f1ef99d437184e5cbbe06adedf5b7a47b
The method User::isBlocked() attempts to answer two questions:
(1) Does the user have a block?
(2) Is the user prevented from performing this action?
The method can answer #1, but it cannot answer #2. Since User::getBlock() can
also answer #1, this method is redundant. The method cannot answer #2 because
there is not enough context in order to answer that question.
If access is being checked against a Title object, all access checks can be
performed with PermissionManager:userCan() which will also check the user's
blocks.
If performing all access checks is not desirable, using
PermissionManager::isBlockedFrom() is also acceptable for only checking if the
user is blocked. This method does *not* determine if the action is allowed,
only that the user's block applies to that Title.
If access is being checked without an existing Title, User::getBlock() can be
used to get the user's block. Then Block::appliesToRight() can be used to
determine if the block applies explicitly to a right (or returns null if
it is unknown or false if explicitly allowed). If the user is creating a new
Title, but the text of the title is not yet known (as in the case of Wikibase),
access should be checked with Block::appliesToNamespace().
Bug: T209004
Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Found by the new ApiUserrights test introduced in 5ab1bee6bc:
> includes/specials/SpecialUserrights.php:462
> includes/specials/SpecialUserrights.php:405
> includes/api/ApiUserrights.php:116
The $tags parameter of the UserrightsPage::doSaveUserGroups()
method must be an array and is not nullable. Fix the caller
to not pass null, but an empty array.
Bug: T182377
Change-Id: Ic9be6a0bddfac023de765c810c07a64d651c33b4
Fixed bug: in PHP versions less than 5.6.0, any request that didn't
attempt to add any groups would warn, because it would call array_fill()
with the second argument (num) equal to 0. From PHP 5.6.0, the num
argument to array_fill() is allowed to be 0.
Change-Id: I0c5772f15d8f550dc43fb37c3c58d15dd73ea584
PHP 7.2 broke existing functionality in making count( null ) raise a
warning. So add tests for null all over the place, or change tests where
we know the value is null or an array (but not false, empty-string, or
0) to just cast to boolean.
Bug: T182004
Change-Id: Idfe23a07daa9f60eee72f2daf04304be87057a29
This feature flag was added to comply with WMF's schema change policy.
It is no longer needed now that the feature is enabled on WMF sites.
External MW installations will run update.php or manually do DB updates
as required before upgrading MW.
Bug: T162517
Change-Id: I5b532d79fd1e8b178490cf2617499ae62967de2c
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 patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
The API 'user' type accepts both user names and IP addresses, and
applies normalization but not canonicalization. We should be using this
on basically every user parameter to ensure that e.g. IPv6 usernames get
uppercased.
Bug: T122803
Change-Id: Ic67fb54061ac311e54f325b2a1a4658f43b8fef4
Prevent blocked users only if they do not have full userrights privleges,
which is the same behavior as implemented in Special:UserRights.
Change-Id: I69557b0951c8fb8b4e7d3ba571b0e5d30782ab4c
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
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 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
Currently, WatchAction::doWatch and WatchAction::doUnwatch return true
always. Let's have them return a status object instead.
This also cleans up the handling of Status objects in some of the API
modules.
Change-Id: I9dd9f0fd499c37f29fa12bcdb6142238a1f11e4d
SpecialPage::getContext called and $mContext is null. Return
RequestContext::getMain(); for sanity
Change-Id: Ie0ed360835164e8a4eb1c675ec8edd944ab95898
For historical reasons, all our API class had a dummy __construct which
simply calls their parent constructor. This patch removes all such
occurences to save out some bytes.
Change-Id: I667955d7821f780fc5ce23823d74dedb1729b9fa
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
action=block/action=unblock can not have the token required because when
using the gettoken param, the token param can not set.
Change-Id: I15317f16c06f150d29c1b17de76f41a6cfa84820
Doxygen choke on text enclosed by '<' and '>' since it tries to
interpret them as HTML or XML elements. This patch adds double quotes
in includes/api/*.php files around the two following strings:
<Firstname>.<Lastname>@gmail.com
<Firstname><Lastname>@gmail.com
Which becomes:
"<Firstname>.<Lastname>@gmail.com"
"<Firstname><Lastname>@gmail.com"
Tested locally, it prevents doxygen 1.8.0 related warnings.
Change-Id: I36d82eb3fd4989ee3ffc65b0b527b83711d1ba69
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
