* specialpages-group-oath
This was for grouping the OATHAuth special pages in their own section, but
we have them in the general users and rights (specialpages-group-users) one
instead.
* oathauth-token
Removed as part of the post-AuthManager clean-up (e38c68c).
* oathauth-invalid-key-type
Used to be thrown from maintenance/UpdateForMultipleDevicesSupport.php
until that support was moved into the database (6ef3d24).
Bug: T354549
Change-Id: I033dbb054733ad88257ef334f451b9ac21430904
This normalises the uses of "tokens" and "scratch"
Not changing all interal usages of "scratch"; comments
and some variables updated. Functions not updated.
Bug: T354031
Change-Id: Icf8626799615f8b95f380db9745e1447519b150a
* Replace "phone" with "device"
* Advise users to mark scratch tokens as used upon usage
* Advice users they're for emergency usage when no access to device
Bug: T150564
Bug: T150868
Bug: T174937
Change-Id: Icd11a4fe00dd63430640ed9d01bc1c30f3c7ca88
The raw svg was represented to a11y dom as 256x256 images (due to
the 'use'). Convert the raw SVG to a base64 encoded img data uri and
provide it with an alt attribute describing the function.
While the qr code is duplicate with the 'manual' code below it, it is
not decorative so should not suppress alt. It's a big image and if
you use touch interaction, it would create a big blank spot. It is
useful to know for users that the QR code is there.
The img wrapping should also make the SVG usage slightly safer. It
avoids any potential remote resource usage from inside the SVG. While
this is not a direct danger right now, compromised php packages can
happen, and this limits the impact in that case.
Bug: T151550
Change-Id: I568927ace95a1fdf9cd7990bc7de8461718aa1c1
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
This is the message that displays right after successfully
introducing username and password. It appears standalone in
a box and misses the final dot.
Change-Id: I7911bb0f9c2ab30756ff53d96d6bda3df6e822b0
If I understand correctly, the messages is about the
"two-factor authentication status of users", so it should
be written as possessive.
Change-Id: I084029d6cdf6288b904f22e9ed2e098a42dbefb0
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
