If the user has a key set but not the oathauth-enable userright, still
show the link to Special:OATH so they can manage it.
This can occur when only restricted groups are allowed to use OATHAuth,
but the user database is shared across multiple wikis.
Bug: T150584
Change-Id: I2db8b47051b0857538e668d233f5cb8586c328a1
Created patch files for other database types.
Note that some types, such as Oracle, are
not guaranteed to work, since not even MW
core works with them yet anyway.
Bug: T67658
Change-Id: Ie9ce8a4d1140d16017c1aa83865f79d8b0986528
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
* Spelling in OATHAuthHooks::onRegistration comment
* Remove incorrect comment for OATHAuth::__construct
* Spelling in TOTPAuthenticationRequest class phpdoc
Change-Id: Iaf670a1b86e82b4684489371c8152b8055bff90e
The first time the extension asks for the code of the mobile phone
isn't an error and shouldn't be styles as such (see the depends-on
change). Change all other UIs to errors.
Bug: T139179
Change-Id: I7cc3333c3e166295e85e91c7b377e53842bdb307
Depends-On: I9a27911613e62b5c4cb86bea40696cb37c4f49c2
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
