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
The `type` log event attribute is used in Wikimedia production logging
to categorize log events by source (e.g. 'mediawiki', 'restbase', etc).
Adding a `type` key to the logging context overwrites the default value
of 'mediawiki'. Rename the key to `throttle` in the context and the
message template.
Change-Id: Ic274159774e43a8749f83c850fff7897956cf377
When the local password provider is in login-only mode, it should
disable itself as soon as some other primary provider is enabled.
It's impossible to tell whether that is the case though, so err in
the safer direction.
Change-Id: Ie77a9cc6d8f06aa52a893e753d9971e30b0f55e5
I found this confusing when reading the code. This should have
identical logic but slightly clearer.
Change-Id: I4918c29bd5dca3642de7bb60219fc246299d952d
An A-type hash is an unsalted hash. A B-type hash is a salted hash of
the form md5(salt "-" md5(password)). So it's not correct to have an
A-type hash with a salt. User::comparePasswords() and
CentralAuthUser::getPasswordFromString() already get this right, they
generate :B: prefixes for legacy salted hashes where the salt is not
specified in the database.
Change-Id: Icb809274f9f63641e54daf98332a5646fd58b550
Logstash merges the log context into the main metadata (where
'message' is the log message) and ends up overwriting the message.
Bug: T145133
Change-Id: I27f221b0f1f7203e93d1b92119dc584ba8526f5b
This adds support for multiple count-per-period limits and arbitrary
period durations in the AuthManager account creation throttle in the
wiki settings. The $wgAccountCreationThrottle config variable becomes
an array like $wgPasswordAttemptThrottle.
Bug: T146290
Change-Id: Iea182a92a1199b0ce7103ab9ae24f1c87b01985c
This commit changes the way how HTMLForm handles a Status object
when executed from a request. It now handles, beside the errors,
also the warnings of a Status object and prints them out, wrapped
in a warning box.
The LoginSignupPage uses this feature to show informative warnings
actually as warnings and not as more disturbing error messages.
Error messages should be reserved for errors and only for erros. An
AuthenticationProvider, which returns an UI AuthenticationResponse
can choose, if the given message is an error or a warning message.
This commit also addds a new function to Status, which allows a
developer to split the object into two new Status objects, where one only
contains the errors and the other only the warnings of the origin
Status object (splitByErrorType). StatusValue also has a new function,
splitByErrorType(), to support this.
Bug: T139179
Change-Id: I9a27911613e62b5c4cb86bea40696cb37c4f49c2
AuthManager tries to check whether the user already exists if
User::addToDatabase fails in autocreation, but since the same DB row
was already checked a few lines earlier and this method is typically
wrapped in an implicit transaction, it will just re-read the same
snapshot and not do anything useful. addToDatabase already has
a check for that so let's rely on that instead.
Bug: T145131
Change-Id: I94a5e8b851dcf994f5f9e773edf4e9153a4a3535
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
Barring ChronologyProtector failure (which itself falls back
to waitForReplication) on account creation, this should be fine.
Change-Id: I94be86c8f56e9e98a9d06814b33a9f08a9228db6
This can allow AuthenticationRequests to flag certain fields as
sensitive, so e.g. the API can insist they be in the POST body rather
than in the query string.
Change-Id: I7b12aa4cd8f5a570f0df7213c0f9084b5a4d4de7
* 81be9512a022 should obviate the main desire for this.
The normal commit step is now relied upon again.
* 820f5d6ce5 and a26fbb6705 enforce DBO_TRX transactions.
* Committing the implicit transaction(s) prematurely is bad
for web request and cross-DB transactionality. Only code
that has clear outermost DB context (e.g. jobs/maintenance)
should be doing things like this as it becomes hard to reason
about (e.g. how much the request/caller needs atomicity
or whether there is an outer (start|end)Atomic section).
This reverts commit 83c66caa08.
Change-Id: I1a5533b239e53f2089f239651c6fdf97e51c9062
AuthManager::getAuthenticationRequests() changes
AuthenticationRequest::$required from REQUIRED to PRIMARY_REQUIRED
if the request is from a primary; it made an exception when
all primary providers returned a given request. That exception is
not particularly useful (AuthenticationRequest::mergeFieldInfo()
used to rely on it to determine which fields are required, but
since I9d33bd2 that's not really needed), and knowing which request
is from a primary is useful for other means.
This changes required field semantics in a corner case: when a
primary provider returns two required requests, the previous
behavior was to assume that they are both required; the new one
is to treat them as alternatives (as if they were returned by
two different providers). So when all primary providers return
request X, and one of them returns Y in addition, the fields of X
will not be marked required, while previously that would have been
the case.
Instead of overcomplicating the interface for something that is
unlikely to come up in any real use case, add a new requirement
to PrimaryAuthenticationProvider that it should not return
multiple required requests.
Bug: T141471
Change-Id: I1c1f44d4d6b66f77c876e3459fb97f03483db744
As things stand now, DBO_TRX or DBO_DEFAULT will cause a transaction to
be started, and then anything in the entire request failing will
probably cause the newly-added user row to be lost. But updates to
external databases (e.g. CentralAuth) likely won't be since those DB
connections were probably shut down after the update was completed.
So let's explicitly commit changes af the end of auto-creation so that
problems with the request itself don't undo it.
Bug: T119736
Change-Id: I6c13c8feb86d8b9a01df894733c38445d048fea0
