Deprecated since 1.27, unused in deployed code.
There's one usage in one extension that's already broken for other reasons
Bug: T249181
Change-Id: I2b868060dd394fb29e389628b659c0d1b3f11833
Remove call to AbstractBlock::appliesToRight, because it always
returns true for 'edit', so checking it is equivalent to adding
&& true.
Although this method is deprecated, this is worth tidying this up
since it is confusing and gets us one step closer to removing the
'edit' case altogether.
Change-Id: I479d6c866ec13a791873042e623fa841dd5bebf2
It was previously forging keys without any makeKey() call in a way
that does produce the same string regardless of wiki, however
bypassing makeKey() means the cache key might end up containing
illegal characters (and thus fatal). It also means that any
logic for detecting local vs global keys for sharding purposes
would wrongly intepret this as a wiki-local key which could cause
split-brain scenarios.
Bug: T246991
Change-Id: I83d0e11d84e3cdcfc8916b2a9b8d85db7c42d2a7
Deprecating something means to say something nasty about it, or to draw
its character into question. For example, "this function is lazy and good
for nothing". Deprecatory remarks by a developer are generally taken as a
warning that violence will soon be done against the function in question.
Other developers are thus warned to avoid associating with the deprecated
function.
However, since wfDeprecated() was introduced, it has become obvious that
the targets of deprecation are not limited to functions. Developers can
deprecate literally anything: a parameter, a return value, a file
format, Mondays, the concept of being, etc. wfDeprecated() requires
every deprecatory statement to begin with "use of", leading to some
awkward sentences. For example, one might say: "Use of your mouth to
cough without it being covered by your arm is deprecated since 2020."
So, introduce wfDeprecatedMsg(), which allows deprecation messages to be
specified in plain text, with the caller description being optionally
appended. Migrate incorrect or gramatically awkward uses of wfDeprecated()
to wfDeprecatedMsg().
Change-Id: Ib3dd2fe37677d98425d0f3692db5c9e988943ae8
1. User::addGroup has to be allowed to update the old group
2. Replace use of string constants to identify cache class,
that's prone to typos and errors. Instead, use private constants
3. Update cached user group memberships in place upon modification.
Before UserGroupManager, we've used to do that - this saves some
DB queries, and is better for correctness - for example UserrightsPage
is adding new memberships and then immediately reads from replica,
expecting it's changes to be there already.
We do not know however how many other cases there are which rely
on this pattern, so implement in-place cache update.
Bug: T255330
Change-Id: Ia5ae0e22d4156fd5e4b9aa7eeb801902e79803d1
Additionally, User::checkAndSetTouched was made public and
marked as @internal. Eventually, as User class refactoring
continues, I would expect this to be replaced by some service.
Bug: T252621
Change-Id: I53533f494950d08ee5ed1ec54d24958c21e7b3aa
Uses User::getNewMessageLinks, which uses Revision objects
Only caller updated to use a new private method
Bug: T253949
Change-Id: I04c0558916e7216540dd7bd12a2a391a1ed7660a
Introduce a UserGroupManagerFactory and UserGroupManager.
The factory utilizes the same pattern as RevisionStore
for access to user groups of a foreign wiki.
Some user group related methods were ported from User
and UserGroupMembership and deprecated, more methods to
be moved over in future patches, not to make this one to large.
Eventually as all the group-related methods are moved and their
usages are replaced, the need for the UserRightsProxy will disappear,
thus it also will be deprecated and removed. Currently for backwards
compatibility, I've had to create artificial UserIdentityValue
objects in some of the deprecated methods to avoid making transitional
temporary methods in the UserGroupManager that would take user ID
instead of the UserIdentity. All of this will go away once migration
to UserGroupManager is completed.
Bug: T234921
Change-Id: If29c6a03dfdbb80b2e846243f7e384b334da9f07
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
Replaces watchlist notification methods in Title and User classes:
* Title::getNotificationTimestamp -> ::getTitleNotificationTimestamp
* User::clearNotification -> ::clearTitleUserNotifications
* User::clearAllNotifications -> ::clearAllUserNotifications
New service has 67.90% code coverage with pure Unit tests; as well
as integration tests for the DeferredUpdates part
A follow-up patch will deprecate the replaced methods, as well
as document that the `UserClearNewTalkNotification` hook now only
provides a UserIdentity (typehint added in T253435 but until now
a full User was still provided).
Bug: T208777
Change-Id: I6f388c04cb9dc65b20ff028ece607c3dc131dfc5
Moved to the new service are the following User:: methods:
* ::getEditCount
* ::getFirstEditTimestamp
* ::getLatestEditTimestamp
* ::getEditTimestamp
* ::initEditCountInternal
A subsequent patch will replace existing uses in core and deprecate the
User methods.
The new service has 100% test coverage with pure Unit tests.
Bug: T253431
Change-Id: If96f9d41026aa358c0fe269a3e078af5f6f058f2
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
* The hook that's being deprecated is not used anywhere
in MW ecosystem.
* The getNewMessageLinks/getNewMessageRevisionId wasn't
ported to the service, only the DB lookup. The interface
of these two methods is extremelly weird, the idea is that
they should eventually be able to do cross-wiki lookups.
This doesn't belong in the service - with only a single caller,
these methods should be moved out of User and inlined into the
caller instead.
* There's been a little bit of preparation done to T146585#4233276
as the interface of setNewTalk was split into set and remove
with the idea that we gotta require Revision to be passed to
setUserHasNewMessages eventually. B/C is still maintained though
since service-conversion patches are not a right place for making
behavioural changes
* The tests are only integration tests since most of the logic
in the manager is tied up to the database anyway.
Bug: T239640
Change-Id: Ia0a52865970c11066d1089196251f62ffeaa53bb
This converts user options management to a separate
service for use in DI context.
User options are accessed quite early on in installation
process and full-on options management depends on the
database. Prior we have protected from accessing the DB
by setting a hacky $wgUser with 0 id, and relying on the
implementation that it doesn't go into the database to
get the default user options. Now we can't really do that
since DBLoadBalancer is required to instantiate the options
manager. Instead, we redefine the options manager with
a DefaultOptionsManager, that only provides access to
default options and doesn't require DB access.
UserOptionsManager uses PreferencesFactory, however
injecting it will produce a cyclic dependency. The problem
is that we separate options to different kinds, which are
inferred from the PreferencesFactory declaration for those
options (e.g. if it's a radio button in the UI declaration,
the option is of multiselect kind). This is plain wrong,
the dependency should be wise versa. This will be addressed
separately, since it's requires larger refactoring. For now
the PreferencesFactory is obtained on demand. This will be
addressed in a followup.
Bug: T248527
Change-Id: I74917c5eaec184d188911a319895b941ed55ee87
This is a re-submit of 35da1bbd7c, which was accidentally merged before
CR (and reverted with aa4da3c2e8).
The purge() method handles purging of both file cache and CDN, using
a PRESEND deferred update. This avoids code duplication and missing
file cache purge calls.
Also:
* Migrate HTMLCacheUpdate callers to just directly using HTMLCacheUpdateJob
* Add HtmlFileCacheUpdate class and defer such updates just like with CDN
* Simplify HTMLCacheUpdate constructor parameters
* Remove BacklinkCache::clear() calls which do nothing since the backlink
query does not actually happen until the job runs
Bug: T230025
Change-Id: Ic1005e70e2c22d5bd1ca36dcdb618108ebe290f3
This replaces User::isValidUserName, ::isUsableName, ::isCreatableName,
::getCanonicalName, and ::isIP.
Unlike User::isIP, UserNameUtils::isIP will //not// return true
for IPv6 ranges.
UserNameUtils::isIPRange, like User::isIPRange, accepts a name and
simply calls IPUtils::isValidRange.
User::isValidUserName, ::isUsableName, ::isCreatableName,
::getCanonical, ::isIP, and ::isValidRange are all soft deprecated
A follow up patch will add this to the release notes, to avoid merge
conflicts.
Bug: T245231
Bug: T239527
Change-Id: I46684bc492bb74b728ff102971f6cdd4d746a50a
Includes the new $wgWatchlistExpiry feature flag.
Consumers of WatchedItem and WatchedItemStore have not been changed to
make use of expiries, this along with associated UI changes will be done
in a separate patch.
Bug: T245213
Change-Id: Ifff5e56e0222bb325cf796e0aa3d88825820d1fd
The name of the parameter makes it sound like it overrides the
default value for that option, but it actually doesn't.
Change-Id: I9797696990aafad4b5fc2a62ace739d485315b73
Done:
* Replace LanguageConverter::newConverter by LanguageConverterFactory::getLanguageConverter
* Remove LanguageConverter::newConverter from all subclasses
* Add LanguageConverterFactory integration tests which covers all languages by their code.
* Caching of LanguageConverters in factory
* Make all tests running (hope that's would be enough)
* Uncomment the deprecated functions.
* Rename FakeConverter to TrivialLanguageConverter
* Create ILanguageConverter to have shared ancestor
* Make the LanguageConverter class abstract.
* Create table with mapping between lang code and converter instead of using name convention
* ILanguageConverter @internal
* Clean up code
Change-Id: I0e4d77de0f44e18c19956a1ffd69d30e63cf51bf
Bug: T226833, T243332
Released just now.
Many old suppressions can now be removed. Enabling the issue for
undeclared variables is left to do later, given that there are
roughly 200 warning.
Change-Id: I99462a1e9232d6e75022912e2df82bc2038476ef
This code can not guarantee the return values are strings, and doesn't
need to, as far as I can tell. There is no need to enforce these values
to be strings at this point, even if user options will typically become
strings later, after being stored in the database.
Change-Id: Ia09064018aed34fff6f94d7a43036f16fed1a864
Extension Gadgets use a boolean value for $defaultOverride.
Also fix the return type for getOption and getDefaultOption.
This change is needed to pass the tests in
I255237574e76f1c0d92f376bc8cbb81f7cb4ed14.
Change-Id: I92ecaa9c14e5c8ba32d152a9e2246a2144b1c7da
This changes User::getActorId() to include the user name and id
when throwing an exception. This doesn't solve the problem
reported in T211450, but should allow the the probelmatic user
name to be identified.
Bug: T211450
Change-Id: Ie83ce6ad6b5ef18ea44a52e204f580cd9c992148
Scalar casts are still allowed (for now), because there's a huge amount
of false positives. Ditto for invalid array offsets.
Thoughts about the rest: luckily, many false positives with array offsets
have gone. Moreover, since *Internal issues are suppressed in the base
config, we can remove inline suppressions.
Unfortunately, there are a couple of new issues about array additions
with only false positives, because apparently they don't take
branches into account.
Change-Id: I5a3913c6e762f77bfdae55051a395fae95d1f841
Drawing from comments associated with `User::newSystemUser` for
checking if a user is a system user, a new method, `User:isSystemUser`
is split out to avoid duplication elsewhere.
Bug: T237356
Change-Id: I73f25a10df2c28a69f612eb1db3e91b7125383d9
To avoid preference bloat, this preference is hidden unless the new
sysadmin config $wgSearchMatchRedirectPreference is set.
Bug: T235263
Change-Id: Ic16f53a4e6ddb6da071d63cd5da28d937d4692c8
Various maintenance scripts assume reserved usernames like
"MediaWiki default" exist, but since they're reserved
User::isUsableName() returns false and therefore the actor migration
created them as anonymous actors. Which would then prevent those
maintenance scripts from using User::newSystemUser() to ensure they
actually exist.
This adjusts User::newSystemUser() to be able to create users for
those anonymous actors.
This also adjusts uses of "MediaWiki default" in core to create it as a
system user.
Bug: T236444
Change-Id: I59a646df36ff9343cc43c05aa20b2b69b2ee124a
The method was soft-deprecated in 1.34. It's not used in any WMF
installed extensions or the tarball, so it can be hard deprecated.
Bug: T220191
Change-Id: I2f48d62a8dd3592918a6197168d31a1e08bd2a3e
The method was soft-deprecated in 1.34, all usages in
WMF installed extensions or tarball installation were removed.
Depends-On: Icb739a3fbf54f5926ca1b661a8707a043ebf09f1
Bug: T220191
Change-Id: I0ee797be35d5278bd081dd07c483e69d9cba6244
Deprecate mBlock, mBlockedby and mHideName as public properties,
since they allow the user to be put into an inconsistent state.
These properties were previously used by now-deprecated hooks
(bf5464614b, af24fc1a7a) and tests.
Bug: T229035
Change-Id: Ia657eaf8b5e4a77ff9df84eb706de1030e17c3bd
This reverts commit 5f06efb318, which
reverted 9335363789, which makes
the deprecated property AbstractBlock::mReason private.
After 9335363789, AbstractBlock::mReason is obsolete, since the block
reason is now stored as a CommentStoreComment, AbstractBlock::reason.
Change-Id: Ica0a74be90383689ca8e4cfe6d0fb25c9a5942c5
This reverts commit 9335363789.
Reason for revert: It's full of code accessing AbstractBlock::mReason
out there, see [1]. Also, it was never hard deprecated. While that may
be acceptable under some circumstances, it's definitely not OK to remove
code when there are consumers around. I'd have fixed it right now without
reverting if it were a single repo, but there's just too many.
[1] - https://codesearch.wmflabs.org/search/?q=-%3EmReason&i=nope&files=&repos=
Change-Id: I8669f502b50cff89e28dada0f65fe2b130ae9b37
AbstractBlock::setReason now accepts a string, Message or
CommentStoreComment. The CommentStoreComment is accessed via
AbstractBlock::getReasonComment.
AbstractBlock::getReason returns the reason as a string, with
the language and format consistent with how block reasons were
built before this commit. This method is deprecated, since it
makes assumptions about the language and format needed. The
deprecated mReason property is no longer public.
Doing this (and T227005) will remove the implicit dependency of
BlockManager::getUserBlock on language, which causes a recursion
error if the block is checked before the user has loaded. It also
provides a mechanism for getting the block reason in a language
specified by the caller. (This does not apply to DatabaseBlock
reasons entered via the Special:Block form, which were not and
are still not translatable.)
This commit also updates authentication classes to return the
translated reason.
Bug: T227007
Change-Id: Iec36876e930dff96a256aebbdc39cbfb331c244e
These are almost only doc changes, with two exceptions:
1-In LinkHolderArray, int-alike array keys are now cast to int, to be uniform with what we do in other code paths
2-In ExtensionRegistration, changed a line to throw an Exception
immediately, instead of an ExtensionDependencyError. This is because the
latter takes an array with msg and type, but we were passing it a plain
string (and in fact the code was bugged).
Bug: T231636
Change-Id: I8b0ef50d279c2a87490dde6a467a4e22c0710afd
This was previously hardcoded from three places: 1) Upon viewing EditPage,
2) Upon viewing SpecialCreateAccount, 3) For any url if the user is
logged-in (User::loadFromSession/isLoggedIn).
== User::loadFromSession
Performing cookie blocks from here created a circular dependency because
Block may need the user language for localisation, which is determined by
asking the User object. This was previously worked around by using a
DeferredUpdate (T180050, T226777). Moving this logic explicitly to the
end of the pre-send cycle in MediaWiki::preOutputCommit breaks the cycle.
This is also where other request-specific handling resides already.
== Limited effect on unregistered users
When an unregistered user performs an edit, and gets blocked,
the cookie block is not applied until they open built-in editor
or CreateAccount page. This makes it more likely for a user's
IP to change meanwhile. Either intentionally, or simply due to
IPs varying naturally (e.g. between mobile locations, or when
going on/off WiFi). By applying it throughout sessioned page
views for unregistered users, it is more likely to get set.
Similar to what was already done for logged-in users.
This commit also makes the intent of not caching EditPage and
SpecialCreateAccount explicit. This was previously implicit
through nothing having called setCdnMaxage() and/or due to
Session::persist being checked for by OutputPage::sendCacheControl.
Bug: T233594
Change-Id: Icf5a00f9b41d31bb6d4742c049feca0039d0c9d9
Blocks are checked from the User object. Specifically,
User::getBlockedStatus instantiates a BlockManager and calls
BlockManager::getUserBlock. However, checking the block often depends
on knowing more about the state than the User should know. As a result,
the global user and request objects were passed into the block manager
on construction.
Whether the global request object should be passed into a service
constructor is still up for debate, so this moves the check for the
global state back to User::getBlockedStatus for now. (Note that it
reintroduces the problem of the User knowing more about state than it
should.)
This change also makes clearer the cases in which
BlockManager::getUserBlock is called from the User.
Different blocks may be sought, depending on the user and their
permissions. The user may be:
(1) The global user (and can be affected by IP blocks). The global
request object is needed for checking the IP address, the XFF
header and the cookies.
(2) The global user (and exempt from IP blocks). The global request
object is needed for checking the cookies.
(3) Another user (not the global user). No request object is available
or needed; just look for a block against the user account.
Cases #1 and #2 check whether the global user is blocked in practice;
the block may due to their user account being blocked or to an IP
address block or cookie block (or multiple of these). Case #3 simply
checks whether a user's account is blocked, and does not determine
whether the person using that account is affected in practice by any
IP address or cookie blocks.
Bug: T231919
Change-Id: I3f51fd3579514b83b567dfe20926df2f0930dc85
This was replaced by GetUserBlock in 7a5508573a.
Handlers in production were updated to use GetUserBlock in
I952aa7d40 and Ibbcd3a239.
Bug: T229035
Change-Id: I95f9fabc6e795243cfe0a1e8737ca6abfb865538
These callers just need to load some data from DB_MASTER.
Subsequent code needing that latest title data should also use the
required flags, rather than relying on flakey global cache state.
Change-Id: I53248ea4b5bf1cd953f956c41b8244831ec5ef04
This was replaced by GetUserBlock in 7a5508573a.
Handlers in production were updated to use GetUserBlock in
Ibbcd3a239.
Bug: T228948
Change-Id: I3e6da73e595e2bd6a96600fe2a6dc68a54d06a2e
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
This allows us to remove many suppressions for phan false positives.
Bug: T231636
Depends-On: I82a279e1f7b0fdefd3bb712e46c7d0665429d065
Change-Id: I5c251e9584a1ae9fb1577afcafb5001e0dcd41c7
And also update approximated counts, which for the most part are lower
than reported (hooray!)
Bug: T231636
Depends-On: Ica50297ec7c71a81ba2204f9763499da925067bd
Change-Id: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
This is the preferred method as it enforces read-only mode for DB_REPLICA
and handles LoadBalancer::reuseConnection() calls automatically.
Change-Id: Iab9439ba8e0810fa14c302661ed7a3534f6bfc0d
I889924037 added a __set method which did not actually handle fields being set.
For better or worse, setting custom fields on ubiquitous objects like User is a
common form of in-process caching, so this is a B/C break; restore for now.
PHP allows creating an array in a previously non-existent object property
with $o->foo['bar'] = $val, but doesn't properly handle that on objects
which have magic getter/setter. Add an ugly hack to make it work (but warn).
Depends on I15090ae9e4b66ac25f631f6179c4394ce8c445a9.
Bug: T227688
Change-Id: I62b80ab4fa10de984cf2c879ab12d91b0fd9bc1c
Also make User::initEditCountInternal take the specific DB handle that
was waited on for replication. This shouldn't make a difference but makes
things more explicit.
Change-Id: Ibb8e083406eb4f4453afce94a2b33450239fce94
Was reverted by I549810a4cd2e424cc4a438887d2f24614a24cc00 due to
T224607.
Original change by Vedmaka Wakalaka was
Ia0d840b772ea5f20c9594ce151cc57adc270e48b.
Original commit message:
The following methods should are factored out of the User class into PermissionManager,
leaving only deprecated stubs:
- User::isAllowed -> PermissionManager::userHasRight
- User::getRights -> PermissionManager::getUserPermissions
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::getGroupPermissions -> PermissionManager::getGroupPermissions
-User::getGroupsWithPermission -> PermissionManager::getGroupsWithPermission
- User::groupHasPermission -> PermissionManager::groupHasPermission
- User::isEveryoneAllowed -> PermissionManager::isEveryoneAllowed
- User::getAllRights -> PermissionManager::getAllPermissions
Depends-On: I7909e9bd6bbfbd708c0a00b861a9b22a38c6665d
Bug: T218558
Bug: T223294
Change-Id: I8899240378f636ea70f447616710516c0a3c5c31
User needs to load user preferences to get preferred language, which
calls User::load() which calls User::loadFromSession().
User::loadFromSession() tries to load blocks which might use messages
which need user language which calls User::load() because the previous
call to it haven't completed yet...
We have a protection against infinite recursion to prevent this from
completely crashing MW, however this patch fixes the main issue: loading
too much stuff when a User is initialized.
Bug: T180050
Change-Id: I63af6d2239b36124d5ed382b8d2aab82c8d54d69
Create a CompositeBlock class which extends AbstractBlock and
adds the property $originalBlocks. This is for situations where
more than one block applies to a user/IP, and avoids the need
to choose just one of these blocks to enforce.
Behaviour of the resulting block is determined by combining the
strictest parameters of the original blocks.
Also add DatabaseBlock::newListFromTarget, which is similar to
DatabaseBlock::newFromTarget, but returns all relevant blocks,
rather than choosing the most specific one.
For tracking a CompositeBlock with a cookie, examine the
original blocks and only track the first trackable block that
is found.
Bug: T206163
Change-Id: I088401105ac8ceb2c6117c6d2fcdb277c754d882
Move the cookie blocking logic into one place. Specifically, move
these methods to the BlockManager:
* User::trackBlockWithCookie
* DatabaseBlock::setCookie
* DatabaseBlock::clearCookie
* DatabaseBlock::getCookieValue
* DatabaseBlock::getIdFromCookieValue
* AbstractBlock::shouldTrackWithCookie
After this, BlockManager::trackBlockWithCookie should be called to
track a block, and BlockManager::clearBlockCookie should be called
to unset the cookie. The other methods in the above list are
helper methods that are made private or marked internal.
Also update places in core that call User::trackBlockWithCookie to
BlockManager::trackBlockWithCookie
Bug: T225141
Change-Id: I818962c6932c01c841a549a101637e00a7593e48
Keep Block as a deprecated class alias for DatabaseBlock.
Update calls to the Block constructor and Block static
methods from external classes.
Also update documentation in several places that refer to
blocks as Blocks.
Bug: T222737
Change-Id: I6d96b63ca0a84bee19486471e0a16a53a79d768a
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
Stop-gap solution for the problem described in T222212.
Force the User ID and Actor ID to zero for users loaded
from the database of another wiki, to prevent subtle data
corruption and confusing failure modes.
Bug: T222381
Change-Id: Ic585f972d61da136744d080df13d8eb1ecd04cf5
I wasn't able to port some places that rely on isAllowed, getOption, or
related methods.
This adds isRegistered() to UserIdentity, which works like
User::isLoggedIn() but with a better name.
I also cleaned up User mocks in WatchedItemQueryServiceUnitTest in the
course of debugging test failures when switching them to
UserIdentityValue instead of mock Users where possible. They now specify
explicitly which methods are allowed to be called on their User objects,
which I believe is good practice for mocks (and unfortunately PHPUnit
makes it awkward).
Bug: T207972
Depends-On: I883d506197a011fe4c102b72df4d9deb58ab5ca2
Change-Id: Iadbf7bc31a496899dbef44e49065ff89f37aea89
This patch makes sure, that idFromName always returns either an int
or null value. The $idCacheByName can contain string values so we cast
the values if necessary.
An alternative could have been to make sure that just int values go
into the cache. But since the cache is public the current approach
to seems to be better atm.
Change-Id: I3085d89b93db2b888c190ba193623b86dc93759a
This introduces a minimal BlockManager service, for getting blocks
that apply to a User.
Move the part of User::getBlockedStatus that checks for the blocks
into BlockManager::getUserBlock, and move the related helper
methods from User to BlockManager.
Hard deprecate or remove these helper methods, and move to private
methods in the BlockManager:
* User::getBlockFromCookieValue
* User::isLocallyBlockedProxy
* User::inDnsBlacklist
Soft deprecate these helper methods, and move to public methods in
the BlockManager:
* User::isDnsBlacklisted
Add tests to cover the methods moved to BlockManager.
Bug: T219441
Change-Id: I0af658d71288376735cebe541215383b56bb72e5
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
Rather than have the behavior vary and possibly break code or tests
when small changes happen, make User/NameTableStore more explicit
about when cache key purges happens.
This should reduce problems with certain fragile tests, such as those
that could be affected by 0390811263 when --use-normal tables is not
used. Ideally, any fragility should be ironed out of effected code.
Change-Id: Ibe5d1bb4bece2526bc0da99648f7ba73bdc0ffa5
Usage:
https://codesearch.wmflabs.org/search/?q=(%3A%3A%7C-%3E)randomPassword%5C(&i=nope&files=&repos=
Only TwitterLogin (an unmaintained) extension still using it and
this patch I2c8d395dd2296a233f4 removes it.
Depends-On: I2c8d395dd2296a233f46abd44b89604c579c3020
Change-Id: I549d536e3c3e1da1c0c9c768640351bddf1d3449
First iteration of adding a PermissionManager service as a replacement
for Title::userCan and User::isBlockedFrom methods.
- Created PermissionManager service
- Migrated Title::userCan to PermissionManager::userCan and deprecated the first
- Migrated Title::quickUserCan to PermissionManager::quickUserCan and deprecated the first
- Migrated User::isBlockedFrom to PermissionManager::isBlockedFrom and deprecated the first
Same for User::isBlockedFrom and PermissionManager::isBlockedFrom - the
$user parameter is now required so the declaration is changed from
isBlockedFrom( $title, ... ) to isBlockedFrom( $user, $title, .. ) which
means before User::isBlockedFrom removal all calls to it need to be updated.
Added PermissionManagerTest, it copies TitlePermissionTest but uses
PermissionManager instance instead of Title methods, this way keeping both tests
in place, we can ensure that nothing was broken and both are in working state
during the deprecation phase.
Bug: T208768
Change-Id: I94479b44afb3068695f8e327b46bda38e44e691f
Statically caching the default user options means tests that change
the inputs, and expect to see the result in their code, are foiled
and the reasons shrowded in mystery. Recalculate default user options
on a per test basis.
Change-Id: I9075cc9c05546a857850e8b4b4dea9f51873451b
User::trackBlockWithCookie and PasswordReset::isBlocked make decisions
about block behaviour based on the block parameters. This should be
done in the Block class.
Bug: T218905
Change-Id: Ia3f46abacdaf70e720b715b39dc60aed53be2d0a
Use getters and setters for $mReason, $mTimestamp, $mExpiry and
$mHideName; use Block::getType to check if a block is an autoblock
instead of checking $mAuto; no change needed for $mParentBlockId,
which is not accessed externally.
Change-Id: I767ed44ce4c2e21f53962d75fb86891add2282f6
User::isAllowed() triggers session loading, which results in a loop
if it is called during session loading. Session providers need to
check block status when $wgBlockDisablesLogin is enabled, so try to
avoid isAllowed calls in that situation.
Bug: T218608
Change-Id: Iab24923c613d6aeed4b574f587fc4cee8f33077c
When setting a cookie on IP blocks was rolled out we wanted to
add some form of measurement to keep an eye on it. This patch is
removing that implementation 'cause it is not needed anymore.
Bug: T218596
Change-Id: I33ee164157b539560a3d88c6f3018dc013218640
$wgUser is not guaranteed to exist until MediaWiki has been fully
initialized; block status needs to be checked early on for
authentication-related permission checks.
Bug: T218608
Change-Id: I16315c071855024bc0412d5360c95f843420d9a9
Ensuring the new value is at least as high as 1 second higher
than the current value is sufficient.
The main code paths using this are checkAndSetTouched (for user group
changes) and saveSettings(), both of which use makeUpdateConditions() which
ensures we bail out if something else already wrote to it in the mean time.
As such, there is no longer a need to make sure our time is higher than
something another server may have written, given that is no longer something
we support.
This variable was introduced in 2005 (MW 1.4) with r9403 (1d12276bcb),
and factored out as newTouchedTimestamp() in 2007 (MW 1.8)
with r16772 (c1094ba987).
Change-Id: I940fb0dd125286a4a348c11e2c8d197f9288a75d
Password policy checks that fail and have `suggestChangeOnLogin` set to true will
prompt for a password change on login.
Below are some rules that apply to this setting in different scenarios:
- If only one policy fails and has `suggestChangeOnLogin = false`, a password change will
not be requested
- If more than one policy fails and one or more have `suggestChangeOnLogin` set to true`,
a password change will be requested
- If `forceChange` is present in any of the failing policies, `suggestChangeOnLogin` value
will be ignored and password change will be enforced
- if $wgInvalidPasswordReset is set to false `suggestChangeOnLogin` is ignored
IMPORTANT**
Before this patch, suggesting a password change was the default behavior (depending on
$wgInvalidPasswordReset), which means that the necessary changes to $wgPasswordPolicy
need to be in place before this patch is merged and gets to production.
Bug: T211621
Change-Id: I7a4a0a06273fa4e8bd0da3dac54cf5a1b78bb3fd
This will be used by the GrowthExperiments
Mentorship module to show when a user made their
latest contribution.
* Introduce a private function to reduce duplication with
getFirstEditTimestamp()
* Add unit tests for both
Bug: T216631
Change-Id: Ica3e6e7165496bdc9b8f12972cf93847ecfffa50
The most notable improvements I was able to fit into this patch can be
seen in the User class, as well as in AbstractRestriction.
Our documentation generator ignores the @const tag. It's not needed. Just
have a comment above a constant and it will show up in the generated
documentation.
Using @var is misleading because a constant is not a "variable". The type
of a constant is strictly derived from it's value. Documenting the type
typically does not provide useful information. Doxygen does not understand
the type, but ignores any @… tag and renders everything else as plain text.
I can split this patch if you prefer. Please tell me.
Change-Id: I8019ae45c049822cdc1768d895ea3e3216c6db5f
Block::prevents plays several different roles:
* acts as get/setter for Boolean properties that correspond to
ipb_create_account, ipb_block_email and ipb_allow_usertalk
* calculates whether a block blocks a given right, based on Block
properties, global configs, white/blacklists and anonymous user
rights
* decides whether a block prevents editing of the target's own
user talk page (listed separately because 'editownusertalk' is
not a right)
This patch:
* renames mDisableUsertalk to allowEditUsertalk (and reverses the
value), to match the field ipb_allow_usertalk and make this logic
easier to follow
* renames mCreateAccount to blockCreateAccount, to make it clear
that the flag blocks account creation when true, and make this
logic easier to follow
* decouples the block that is stored in the database (which now
reflects the form that the admin submitted) and the behaviour of
the block on enforcement (since the properties set by the admin
can be overridden by global configs) - so if the global configs
change, the block behaviour could too
* creates get/setters for blockCreateAccount, mBlockEmail and
allowEditUsertalk properties
* creates appliesToRight, exclusively for checking whether the
block blocks a given right, taking into account the block
properties, global configs and anonymous user rights
* creates appliesToUsertalk, for checking whether the block
blocks a user from editing their own talk page. The block is
unaware of the user trying to make the edit, and this user is not
always the same as the block target, e.g. if the block target is
an IP range. Therefore the user's talk page is passed in to this
method. appliesToUsertalk can be called from anywhere where the
user is known
* uses the get/setters wherever Block::prevents was being used as
such
* uses appliesToRight whenever Block::prevents was being used to
determine if the block blocks a given right
* uses appliesToUsertalk in User::isBlockedFrom
Bug: T211578
Bug: T214508
Change-Id: I0e131696419211319082cb454f4f05297e55d22e
This begins work on making namespaces a valid restriction type. The CRUD
operations of BlockRestriction can now handle namespaces. Since
NamespaceRestriction implements Restriction, enforcement should start working
immediately, but testing enforcement will come in a subsequent patch since it's
impossible to create them.
Bug: T204991
Change-Id: I7264b452d9ad788c146d6ea25d01d4d7cb5ac4f6
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
Adds a way to set an array of options for a password policy. Currently
there is one option, 'forceChange', which forces the user to change
their password (if it fails the given check) before logging in.
Bug: T118774
Change-Id: I28c31fc4eae08c3ac44eff3a05f5e785ce4b9e01
Without it, Special:UserRights sometimes fails with a bogus conflict error
just because groups are somehow ordered differently.
Bug: T164211
Change-Id: I9c7f51338e0849d9e134dc780eb13c542960c655
Unused, the return format does not seem useful.
Also improve the documentation of $wgPasswordPolicy
and PasswordPolicyChecks.
Change-Id: Ic01e80cfefc4cfb0eee1eccc6a66942f692278a0
No changes for sitewide blocks when "Prevent user... edit own talk page"
is checked. On partial blocks, this option will be disabled and ignored. All users
will be allowed to edit their own talk page unless a page restriction
for their page is in place.
New rules will be implemented for Namespace restrictions in a different
patch when Namespace blocking is ready.
Bug: T210475
Change-Id: I096edf2887441bccd59f09bf0eceb3988b36db1e
The user_id is an unsigned integer in the database. But not all database
abstractions we use are guaranteed to return integer values as PHP
integers. Sometimes it's a string and needs an integer cast first.
Want proof? Search for usages of this method. Almost all add an (int)
cast. This is weird and should not be necessary.
Change-Id: If1d706f73350fca5b3a0f1e0de59e4518162445b
When MySQL is using repeatable-read transaction isolation (which is the
default), the following sequence of events can occur:
1. Request A: Begin a transaction.
2. Request A: Try to select the actor ID for a user. Find no rows.
3. Request B: Insert an actor ID for that user.
4. Request A: Try to insert an actor ID for the user. Fails because one
exists.
5. Request A: Try to select the actor ID that must exist. Fail because of
the snapshot created at step 2.
In MySQL we can avoid this issue at step #5 by using a locking select
(FOR UPDATE or LOCK IN SHARE MODE), so let's do that.
Bug: T210621
Change-Id: I6c1d255fdd14c6f49d2ea9790e7bd7d101e98ee4
blocked' option on partial blocks.
Partial blocks currently ignore this option as it gets into an edge case. The
option should take precidence if it is true, but should be ignored if it is
false. On sitewide blocks, the option should always be honored.
Bug: T210475
Change-Id: I33177b48a5c261ec3f510ce01998c1b096077b85
The fix applied in d67121f6d took care of the immediate issue in
T208398, but after further analysis it was not a correct fix.
* Near line 770, the method shouldn't even be called unless the target
is TYPE_USER.
* Near line 1598, it isn't dealing with a target at all.
* Near line 1813, you're not going to get a sensible result trying to
call `$user->getTalkPage()` for a range or auto-block ID. What you
would really need there to handle range and auto-blocks correctly is
to pass in the User actually making the edit.
But after some pushback in code review about passing the User into
Block::preventsEdit() to make line 1813 work, we'll instead replace the
method with Block::appliesToTitle() and put the check for user talk
pages back into User::isBlockedFrom().
Bug: T208398
Bug: T208472
Change-Id: I23d3a3a1925e97f0cabe328c1cc74e978cb4d24a
If $name is a User object, some code magically works because the object
gets converted to a string, but other code blows up because objects
aren't valid array keys. Prevent this from happening by explicitly
forcing $name to be a string.
Bug: T208469
Change-Id: Icc9ebec93d18609605e2633ccd23b90478e05e51
Non-breaking change. Remaining uses are public interfaces (a constant, two
globals, a config sub-parameter, SQL queries, storage function names), one i18n
message key, and a whole lot of maintenance scripts with calls to the deprecated
function wfWaitForSlaves().
Change-Id: I6ee5ca92ccf6a80c08f53d9efe38ebb4b05064d7
Use these in place of various wfWikiID() calls.
Also cleanup UserRightsProxy wiki ID variable names and removed unused
and poorly named getDBname() method.
Change-Id: Ib28889663989382d845511f8d34712b08317f60e
