Configure "ActionFilteredLogs" in extension.json to allow filtering
the oath log by its two actions, verify ("checking" in the UI) and
disable-other.
== Test plan ==
* Enable 2FA on your administrator account, use Special:VerifyOATHForUser
and Special:VerifyOATHForUser to generate two log entries.
* Visit Special:Log/oath and use the new action selector, testing each
state to verify the correct set of logs are shown.
* Screenshots showing this testing are posted at T310487#7999991.
Bug: T310487
Change-Id: I10632c86689e330b21b44a096b098436ebe47e3e
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
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
- When explictly disabling a method
- When method is implicity disabled if user switches to another method
Bug: T232008
Change-Id: I97a96ca7c1935ecb3a81aea35f607b8ff9f8817d
Help messages for 2FA in general and for TOTP module are taken from Wikipedia.
Those could probably be improved, any suggestions are welcome
Bug: T218214
Bug: T226056
Change-Id: Ifc81a3c0e1adc9f6d0d49e7eee086714fc2c0f81
It's better that we add for when someone enables or disables for self too
But that can be done in a follow-up patch
Bug: T180896
Change-Id: Ic173ebb7e39d22e40fea23c2b906d246adef1e05
Validating with a scratch code is probably a "giant trap that newbies
could fall into".
Bug: T150824
Change-Id: I5710b151d7682e4cdb0b6a692f7b2c108f051caf
Rename this key from failedtovalidateoauth to failedtovalidateoath
as it has nothing to do with OAuth
Bug: T151536
Change-Id: Ib34ef3dbdef8eda515748140960ef240e4990044
To make clear from the message name which module it belongs to, two
example messages should be renamed.
Change-Id: Idd329e77d5c7082eb8097309fb89f82c7a37cf68
