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
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
Hook was part of Extension:OpenStackManager, but removed by REL1_35, so unnecessary
I4741fcb073f8463f017bc1b477206dee801b662b / 46d9149c2db7c2b2d4573bede74b54779d66bee8
Change-Id: I2c5f99bfa9028c57a1eadbd81a51f84b47668848
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
Since this repository has multi-licensed code, add GPL v2+ file headers
to code that had no licensing blocks to make it obvious which files
carry which license.
And add "AND GPL-3.0-or-later" to extension.json's license-name property
to make it clear that this extension does have code that isn't
redistributable under GPL v2.
Change-Id: Id3059fb9596527ef054bec9d89a28f1ccbe2113d
SPDX released version 3 of their license list (<https://spdx.org/licenses/>),
which changed the FSF licenses to explicitly end in -only or -or-later
instead of relying on an easy to miss + symbol.
Bug: T183858
Change-Id: Ia282470aefef930bd867de521f9c45ded8349193
It's only used as a dependency for one module, so it doesn't really make
sense to have it as a separate module.
Change-Id: I0936073358e98d236ce9440d92873a2ea3851e60
Extend the token validation failure checks introduced in I4884f6e to the
other interactions where OATHAuthKey::verifyToken is used.
Depends-On: Ia3add8bbbab0307f036e9b77e752c382da3a0d04
Change-Id: Icbe5cdf561c683dc971a099d61cedff311b26b43
Add a new internal action=oathvalidate Action API module that can be
used to validate an OATH token collected from a user. Using the module
requires the 'oathauth-api-all' permission introduced in I4884f6e.
Attempts to call the action for a given user are rate limited to only
allow 10 failures per minute using the new 'badoath' key.
The check is primarily useful as an internal network service in an
environment where MediaWiki and other applications are sharing the same
backing authentication store (e.g. LDAP) and the non-MediaWiki
applications would like to respect the OATH protections enabled on the
MediaWiki install.
Complete usage in an LDAP shared auth environment would look something
like:
* Authenticate a user with the LDAP server via auth-bind
* Call action=query&meta=oath as a privileged user to check for OATH
protection.
* If OATH is active for the account, prompt the user for their current
OATH token.
* Call action=oathvalidate as a privileged user to validate the token.
* If validation succeeds, complete authentication.
* If validation fails, do not authenticate the user.
Bug: T144712
Change-Id: I1b18d9f3b99364fc47c760bdfc2047c1cbb5c04a
Add a new internal action=query&meta=oath Action API module that can be
used to check for OATH protection on a given user account. Using the
module requires a new 'oathauth-api-all' permission which is not granted
to any group by default. The permission is also added to the new
'oath' grant so that it can be used via OAuth and bot passwords.
Use of this API is security sensitive and should not be granted lightly.
Configuring a special 'oathauth' user group to grant the needed
'oathauth-api-all' permission is recommended.
This check is primarily useful as an internal network service in an
environment where MediaWiki and other applications are sharing the same
backing authentication store (e.g. LDAP) and the non-MediaWiki
applications would like to respect the OATH protections enabled on the
MediaWiki install.
Bug: T144712
Change-Id: I4884f6efdfa42db82c25eadb70c7aefa98c370e9
Previously there was a race condition where the qrcode would
not show if the startup module finished loading prior to the
div that should contain the qrcode being loaded. This quite
commonly happened on wikipedia during a hit where js is cached
(But does not happen locally, my theory is that that is due to
how packets get split over the network but not from localhost).
Change it to use a normal RL module, as that seems best practise.
Also do not load the qrcode js on special pages that do not use it.
Finially, remove position:top as its not needed.
Bug: T136988
Change-Id: I5139f222207203d834bdc979b21c1fc94f242ac2
