wikimedia/mediawiki-extensions-OATHAuth
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/OATHAuth synced 2024-11-14 11:17:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-OATHAuth/extension.json

119 lines
2.6 KiB
JSON
Raw Normal View History

Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
{
"name": "OATHAuth",
Remove pre authmanager MW support Change-Id: I46712392e48c263bd30b849777caea8e22650d40
2016-10-11 23:47:01 +00:00
"version": "0.2.2",
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"author": "Ryan Lane",
Use HTTPS for the url Change-Id: I3e70181ff28e45466d2559d884486183856a5c40
2016-01-19 22:13:44 +00:00
"url": "https://www.mediawiki.org/wiki/Extension:OATHAuth",
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"descriptionmsg": "oathauth-desc",
"type": "other",
Set license-name in extension.json Change-Id: Ie2457a3e5ffee0377facd4a2f62df5aa0ee4559f
2016-06-23 09:23:18 +00:00
"license-name": "GPL-2.0+",
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"AutoloadClasses": {
Add an api action to validate an OATH token 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
2016-09-30 03:12:03 +00:00
"ApiOATHValidate": "api/ApiOATHValidate.php",
Add a query meta api option to check for OATH 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
2016-09-29 21:31:09 +00:00
"ApiQueryOATH": "api/ApiQueryOATH.php",
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"OATHAuthHooks": "OATHAuth.hooks.php",
Refactor extension key storage 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
2014-05-19 00:05:59 +00:00
"OATHAuthKey": "OATHAuthKey.php",
Encrypt password when stored in user session 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
2016-03-31 04:23:48 +00:00
"OATHAuthUtils": "OATHAuthUtils.php",
Refactor extension key storage 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
2014-05-19 00:05:59 +00:00
"OATHUserRepository": "OATHUserRepository.php",
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"HOTP": "lib/hotp.php",
"HOTPResult": "lib/hotp.php",
"Base32": "lib/base32.php",
"OATHUser": "OATHUser.php",
Refactored special pages into HTMLForm and proxy 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
2014-05-22 07:33:40 +00:00
"SpecialOATH": "special/SpecialOATH.php",
"SpecialOATHEnable": "special/SpecialOATHEnable.php",
"SpecialOATHDisable": "special/SpecialOATHDisable.php",
Move token login to separate page 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
2014-05-27 18:00:21 +00:00
"SpecialOATHLogin": "special/SpecialOATHLogin.php",
Update for AuthManager Handling enabling/disabling via AuthManager is left to a separate patch. Bug: T110457 Change-Id: Ic492b8f2477c475f8414b61505139e9a1df2ba5b
2015-11-16 02:52:23 +00:00
"ProxySpecialPage": "special/ProxySpecialPage.php",
"TOTPAuthenticationRequest": "auth/TOTPAuthenticationRequest.php",
"TOTPSecondaryAuthenticationProvider": "auth/TOTPSecondaryAuthenticationProvider.php"
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
},
Remove pre authmanager MW support Change-Id: I46712392e48c263bd30b849777caea8e22650d40
2016-10-11 23:47:01 +00:00
"AuthManagerAutoConfig": {
"secondaryauth": {
"TOTPSecondaryAuthenticationProvider":{
"class": "TOTPSecondaryAuthenticationProvider",
"sort": 50
}
}
},
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"ExtensionMessagesFiles": {
"OATHAuthAlias": "OATHAuth.alias.php"
},
"Hooks": {
Remove pre authmanager MW support Change-Id: I46712392e48c263bd30b849777caea8e22650d40
2016-10-11 23:47:01 +00:00
"AuthChangeFormFields": [
"OATHAuthHooks::onAuthChangeFormFields"
],
Reintroduce TwoFactorIsEnabled hook Production code in another extension depends on the existence of this hook. Bug: T131445 Change-Id: I3844150801f724f3eb217dc16c26cb76a58aedd8
2016-04-01 20:32:05 +00:00
"TwoFactorIsEnabled": [
Update for AuthManager Handling enabling/disabling via AuthManager is left to a separate patch. Bug: T110457 Change-Id: Ic492b8f2477c475f8414b61505139e9a1df2ba5b
2015-11-16 02:52:23 +00:00
"OATHAuthHooks::onTwoFactorIsEnabled"
Reintroduce TwoFactorIsEnabled hook Production code in another extension depends on the existence of this hook. Bug: T131445 Change-Id: I3844150801f724f3eb217dc16c26cb76a58aedd8
2016-04-01 20:32:05 +00:00
],
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"LoadExtensionSchemaUpdates": [
Update for AuthManager Handling enabling/disabling via AuthManager is left to a separate patch. Bug: T110457 Change-Id: Ic492b8f2477c475f8414b61505139e9a1df2ba5b
2015-11-16 02:52:23 +00:00
"OATHAuthHooks::onLoadExtensionSchemaUpdates"
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
],
"GetPreferences": [
Update for AuthManager Handling enabling/disabling via AuthManager is left to a separate patch. Bug: T110457 Change-Id: Ic492b8f2477c475f8414b61505139e9a1df2ba5b
2015-11-16 02:52:23 +00:00
"OATHAuthHooks::onGetPreferences"
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
]
},
"MessagesDirs": {
"OATHAuth": [
"i18n"
]
},
"config": {
Allow for using separate database for OATH creds 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
2015-05-25 23:47:03 +00:00
"OATHAuthWindowRadius": 4,
Encrypt password when stored in user session 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
2016-03-31 04:23:48 +00:00
"OATHAuthDatabase": false,
Allow override of Site prefix without changing sitename Bug: T147901 Change-Id: Id5b565f9c05b591e3638dbf51dd784224203669c
2016-10-31 14:17:27 +00:00
"OATHAuthSecret": false,
"OATHAuthAccountPrefix": false
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
},
"ResourceModules": {
Fixup qrcode-generating js, to stop race condition. 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
2016-06-20 07:34:42 +00:00
"ext.oath.showqrcode": {
"scripts": [
Get rid of separate ext.oathauth module 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
2016-11-14 05:09:41 +00:00
"jquery.qrcode.js",
"qrcode.js",
Fixup qrcode-generating js, to stop race condition. 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
2016-06-20 07:34:42 +00:00
"ext.oath.showqrcode.js"
]
Hide empty square for QR code with CSS for no-JS users Change-Id: Id557bce14a623d894e0b23123c8ef037ddd3cc53
2016-11-14 05:18:06 +00:00
},
"ext.oath.showqrcode.styles": {
"styles": [
"ext.oath.showqrcode.styles.css"
]
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
}
},
"ResourceFileModulePaths": {
Fixup qrcode-generating js, to stop race condition. 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
2016-06-20 07:34:42 +00:00
"localBasePath": "modules",
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"remoteExtPath": "OATHAuth"
},
"SpecialPages": {
"OATH": "SpecialOATH"
},
Add user right for enabling two-factor auth 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
2015-05-26 00:08:47 +00:00
"AvailableRights": [
Add a query meta api option to check for OATH 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
2016-09-29 21:31:09 +00:00
"oathauth-enable",
"oathauth-api-all"
Add user right for enabling two-factor auth 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
2015-05-26 00:08:47 +00:00
],
"GroupPermissions": {
"*": {
"oathauth-enable": true
}
},
Add a query meta api option to check for OATH 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
2016-09-29 21:31:09 +00:00
"GrantPermissions": {
"oath": {
"oathauth-api-all": true
}
},
"GrantPermissionGroups": {
"oath": "authentication"
},
Add an api action to validate an OATH token 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
2016-09-30 03:12:03 +00:00
"APIModules": {
"oathvalidate": "ApiOATHValidate"
},
Add a query meta api option to check for OATH 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
2016-09-29 21:31:09 +00:00
"APIMetaModules": {
"oath": "ApiQueryOATH"
},
Add an api action to validate an OATH token 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
2016-09-30 03:12:03 +00:00
"RateLimits": {
"badoath": {
Apply rate limits to all token verifications Extend the token validation failure checks introduced in I4884f6e to the other interactions where OATHAuthKey::verifyToken is used. Depends-On: Ia3add8bbbab0307f036e9b77e752c382da3a0d04 Change-Id: Icbe5cdf561c683dc971a099d61cedff311b26b43
2016-10-03 04:32:30 +00:00
"&can-bypass": false,
Add an api action to validate an OATH token 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
2016-09-30 03:12:03 +00:00
"user": [
10,
60
]
}
},
Upgrade Extension:OATHAuth to the registration system Bug: T87949 Change-Id: Id6217249c11922ab7d25b31375789c40d737600c
2015-12-17 21:09:57 +00:00
"manifest_version": 1
}
Reference in a new issue Copy permalink