Notify users when 2FA is disabled on their account in case something was
fishy about it. This notification is a "system" notification that will
be displayed in the web UI and sent over email. It can't be opted out of
as a preference.
The notification links to Special:Preferences, where users can see their
2FA status and re-enable it if they want. A secondary help link goes to
[[mw:Help:Two-factor authentication]], but can be overridden by
adjusting the "oathauth-notifications-disable-helplink" message. The
notification text is different based on whether the user disabled 2FA on
their own, or an admin used the special page or a maint script to do it.
On Wikimedia wikis, we'll use the WikimediaMessages extension to
customize the messages.
The Echo (Notifications) extension is not required, this will gracefully
do nothing if it's not enabled.
Bug: T210075
Bug: T210963
Change-Id: I99077ea082b8483cc4fd77573a0d00fa98201f15
Creating a HTMLForm (or OOUIHTMLForm) without passing in a context is
deprecated now.
Bug: T301866
Change-Id: I35eb85f5089bcef04624e5f72fd1a4389be87de9
Depends-On: Ic65c8934ab33c6d1ca0356011923f8933c5072ca
Users in groups listed in $wgOATHRequiredForGroups (default none) must
have two-factor authentication enabled otherwise their membership in
those groups will be disabled. This is done using the
UserEffectiveGroups hook, which allows dynamically adding or removing
user groups.
If a user doesn't have 2FA enabled, it will appear to them as if they
aren't a member of the group at all. Special:Preferences will show which
groups are disabled. In the future it would be good to have a hook into
PermissionsError to show this as well. The UserGetRights hook is used to
ensure the user still has the "oathauth-enable" user right in case it
was only granted to them as part of the user group they are disabled
from.
On the outside, Special:ListUsers will still show the user as a member
of the group. The API list=users&prop=groups|groupmemberships will show
inconsistent informaiton, groups will remove disabled groups while
groupmemberships will not.
This functionality was somewhat already available with
$wgOATHExclusiveRights, except that implementation has flaws outlined at
T150562#6078263 and haven't been resolved in I69af6a58e4 for over a year
now. If this works out, it's expected that will be deprecated/removed.
Bug: T150562
Change-Id: I07ebddafc6f2233ccec216fa8ac6e996553499fb
This allows iOS/iPadOS/macOS to suggest filling codes from sms/the built in totp authenticator (in upcoming versions).
Bug: T289086
Change-Id: I555b05fad4806a37a95afcbc63e143efc424f9d3
Since AbstractAuthenticationProvider ::setLogger, ::setManager,
::setConfig methods had been soft deprecated,
so its uses were removed.
* Also bump required MW version to 1.37.0
Bug: T281991
Change-Id: Ifd6ed1bc60d8a7fe6d10af1f08b6670a96ca2851
Follows-up c943f75.
* Use foreach to iterate the list of tokens, instead of i-to-length.
* Remove the redundant 'retval = false' assignment, as this was
within an `if (!$retval)` block where the only previous assignment
to it was either retval = 1 or retval = false. Hence redundant.
* Remove the conditional that made the list only checked if the
list was not identical to `[ 0 => "" ]`.
It is unclear to me why this check existed.
I can imagine one of two scenarios, neither of which appears
to be the case:
1. Maybe the scratch list contains 10 tokens plus an empty string,
and if we see it only contains that, we know it's logically empty
and don't "need" to iterate the list.
Except... iterating the list is cheap, so why bother?
2. Maybe the scratch list contains 10 tokens plus an empty string,
and we don't want to allow the empty string to be considered
a valid scratch token to we skip the loop if that's the only
one left.
Except... if that were the case we'd be in trouble as it
isn't being disallowed when the list contains other items
still. And again, afaik it never contains an empty string,
and hopefully empty input is already rejected by now.
Neither of these are good reasons to remove the code without
knowing what it was for though, so I'd rather we figure this
out before merging. I can restore the check if it's non-trivial
to find out.
Bug: T256918
Change-Id: Ide4160bdc18bc47da9632791fb4321e44d6d115a
* Stop returning return values of function that don't return anything
* Remove & from IManageForm reference
Change-Id: I7afa12a4f154cabee03be8947a0bfaadf9598a03
Hook was part of Extension:OpenStackManager, but removed by REL1_35, so unnecessary
I4741fcb073f8463f017bc1b477206dee801b662b / 46d9149c2db7c2b2d4573bede74b54779d66bee8
Change-Id: I2c5f99bfa9028c57a1eadbd81a51f84b47668848
Since T209749, privileged users have an UI to query 2FA status.
We should allow them to do the same thing via the API as well.
Bug: T250901
Change-Id: I28720c762ca595c0ab83aa400f0a593ed6a9285e
It's using wikitext, so it must be given to the parser.
Follow-up to I2abc96bea0543d600c3a48361da1a626d27d5067
Change-Id: Id6d938c2d2d5775d55d3c4c1aeeaa1c002294a9f
Due to using unset(), array keys would be preserved, and therefore, for loop would crash.
Now using array_splice, but had to "reset" the values on construct to fix currently broken
arrays.
Bug: T244308
Change-Id: I6f3dd3df95d5a071b92aa7693ed7ae3fddf35a9d
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: Idb1b91244e653b2ba2e27bceb3eba769577124a9
It's not a query module, so this doesn't actually do anything.
Non query modules are private by default, so ApiMain->setCacheMode()
is not needed
Change-Id: I789edbf0693f8b1928fb32c3aedc0d8899aecc40
