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
During the two-step login, users with OATH enabled need to have their
login details saved into their session while we prompt them for their
OATH code. This encrypts that data, so we don't write their user's
password into our session storage.
Change-Id: I9969871205ac5c438706df41ef1519cb4cd7a964
Rather than have an extraneous form on the login page,
move the token input to a separate page. The actual
logic for logging in is identical, the only difference
is that the token is added to the form data on a second
page request.
Bug: 53195
Change-Id: I39859cc59f1811de42b72f6167d332ea48812f97
Make new right oathauth-enable that the user must have to enable two
factor authentication (disabling and logging in, of course, are still
allowed).
Bug: T100376
Change-Id: I18d43f8b2cf2c2ce9c2309a43961686498b5c999
Add configuration variable for specifying what database the OATH
credentials are stored in, that way wikis that use CentralAuth can
centralize their two-factor authentication data as well.
Bug: T100374
Change-Id: I285e2fe29fee43ddc6c5a6e51823911d43c596f6
Made new class ProxySpecialPage, which acts as a
proxy object to another SpecialPage object that is
determined based on context information other than
the title.
Then Special:OATH has been split into two separate
special page classes (both FormSpecialPages using
HTMLForm) that are routed to by a ProxySpecialPage
object.
In addition, the form for enabling two-factor auth
has been refactored into vform style, with some
better instructions on how to enable two-factor
authentication.
Change-Id: Ib9117cbc9d7f044de9607db81a157e1b472b5ec0
This takes out the actual key information from
OATHUser and puts it into an OATHKey class, which OATHUser
depends on. This allows easily swapping keys in/out from
a user.
Change-Id: Ife5f1bae4ad65b66c5e20017cc43c0576b4aba19
