This allows the backend to do whatever it can to ensure atomicity, and
is also easier to read, since the intent is obvious.
Change-Id: Ibbfecd92a2c6d9a5997ca37ea101e068bd1e8202
* Convert everything that is protected to be private,
since the class is not stable to extend
* Remove PasswordReset::$hookContainer, unneeded
Additionally, add missing UserFactory::newFromRow,
for now just a wrapper for User::newFromRow
Bug: T253432
Change-Id: I1de57a08605ff6e0d2be8e276b7fcb08934fb5da
Deprecate lack of $hookContainer parameter to DefaultPreferencesFactory,
LinkHolderArray and PasswordReset constructors
This was split out from the main patch to create a migration window,
since deprecation messages from extensions now cause Jenkins to vote -1.
Depends-On: Ie097d8e12758f066aee14c740f9e07955aa510c1
Change-Id: I559640c9f4dc7ad5444fe1ef39d50e4504ae0b63
These were never meant to be part of the public interface and should not
ever have been marked with @since. They're only useful for constructing
the respective objects, which no outside users should be doing.
Change-Id: I86e01272d46fc72af32172d8a12b9180971d4613
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
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
Followup patch for: b64b0f5. Show general message when an invalid email
is submitted.
Bug: T249730
Change-Id: I98a35af26930f3d66308065e271e9617fdbf5076
Add logic to reset users array that will receive the reset password email with
numeric keys. The array should have index 0 if it is not empty so that the
password reset process can run without 'Undefined' ErrorException.
Bug: T249709
Change-Id: Idc5456e0d3e77f2ae0542f6b972d168049e51d77
Hide the `requireemail` status from the resetting user when
requesting a password reset without supplying an email address.
Bug: T238961
Change-Id: Iee07564aac78d013ecc52192b536e92cb1ed4e8b
For all successfully submitted (i.e. valid input) password reset
requests, display the same information. This removes the
distinction between email and username resets, and only shows the
user what they've already submitted.
Bug: T238961
Change-Id: Ic17acecf1e44401f7607cdaf90dcee1a26b8405f
Add functionality that does not send password reset email to user accounts that turned on preference
that requires both username and email to be submitted in the PasswordReset form when only email is
provided.
Bug: T234401
Change-Id: I9bddc7073b8bcb52c4287b3d6c7343be29b717f2
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
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
There's a difference between addition of credentials, which doesn't
need to invaliate BotPasswords, and changing or removal of credentials,
which does.
It seems most straightforward for the caller of
AuthManager::changeAuthenticationData() to know which is intended, so
let's add a flag there.
Bug: T199809
Change-Id: Ib8405734e605b94f3f0b66596ad95784cb365e4f
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
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: I6f59febaf8fc96e80f8cfc11f4356283f461142a
If anyone wants such a thing, they can make their own extension.
I asked stewards, and they said they don't use this.
See also T32636 / 9de2bfd1fe
Bug: T150930
Change-Id: I3ab5962dba668e5d628e55ad0c0feae471d82b5e
Special:PasswordReset will take either the username or the email
into account but never both. Reflect this in the way parameters
are passed to the hook.
This also makes sure hook handlers never receive an unsanitized
email address.
Change-Id: I8d3b3d81e0cd5f92e5cd0a866a16695638610592
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
$error might be an array of key + values, but wfMessage() treats that as
an array of alternative message keys instead so the values are lost.
Message::newFromSpecifier(), on the other hand, does exactly what we
want.
Change-Id: I25765869f6888ac793c2af9caaa9bbdf2224d51a
Rewrite authentication-related special pages to use AuthManager.
All the changes mentioned below only take effect when
$wgDisableAuthManager is false.
LoginForm is rewritten to use HTMLForm and split into UserLogin
and CreateAccount; ChangePassword and PasswordReset are rewritten;
ChangeEmail and Preferences are updated. Four new special pages
are added to handle the new capabilities of AuthManager (linked
accounts, secondary authentication providers): LinkAccounts,
UnlinkAccounts, ChangeCredentials, RemoveCredentials.
The old form-based hooks (ChangePasswordForm, UserCreateForm,
UserLoginForm) are deprecated. A new, more generic hook is
available to alter the forms (AuthChangeFormFields);
form changes that involve new fields should be done via
$wgAuthManagerConfig.
UserLoginComplete is limited to web-based login; for more
generic functionality UserLoggedIn can be used instead.
Hooks that assume password-based login (PrefsPasswordAudit,
AbortChangePassword) are removed; the first functionality
is replaced by ChangeAuthenticationDataAudit, the second is
handled by AuthManager. LoginPasswordResetMessage is removed,
the functionality can be recreated via authentication providers.
There are several smaller backwards incompatible changes:
* Adding fields to the login/signup forms by manipulating the
template via the extraInput/extrafields parameters is not
supported anymore. Depending on the authn configuration the
login/signup process might be multistep and it would be
complicated to ensure that extensions can access the data
at the right moment. Instead, you can create an
AuthenticationProvider which can define its own fields and
process them when the authentication is over.
(There is B/C support for a transitional period that works with
the default login form, but might break with configurations that
require multiple steps or redirects.)
* Removed cookie redirect check. This was added in 2003 in 9ead07fe9
for the benefit of bots, but with MediaWiki having an API these days
there is little reason to keep it. Same for the wpSkipCookieCheck
flag (added in 2008 in 29c73e8265).
* Instead of embedding a password field on sensitive special pages
such as ChangeEmail, such pages rely on AuthManager for elevated
security (which typically involves requiring the user to log in again
unless their last login was more than a few minutes ago).
Accordingly, wgRequirePasswordforEmailChange is removed.
* Special:ChangePassword requires login now.
* Special:ResetPassword now sends a separate email to each user when called
with a shared email address.
* the Reason field had a message with 'prefsectiontip' class
which was sorta broken but used in extensions for formatting.
HTMLForm does not support that, so this commit turns it into a help message
which will break formatting. See https://gerrit.wikimedia.org/r/#/c/231884
Bug: T110277
Change-Id: I8b52ec8ddf494f23941807638f149f15b5e46b0c
Depends-On: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
