To do the migration we need to ensure that a single user has rows in
either the old oathauth_users table, or the new oauthauth_devices table,
but not in both.
Also add a missing startAtomic/endAtomic.
Bug: T242031
Change-Id: Ib0d42370b7206ff031873182c3fd957449656de8
This adds new database tables to support storing multiple authentication
factors for a single user. The current approach taken is to use a single
database row per 2fa method and key. The current module/key abstraction
will have to be updated to support having multiple module types for a
single user (for example for having a separate module for recovery
codes), but this patch does not address that and instead keeps the
existing limitations, however the needed updates for that should be
doable with this database schema.
I've decided to add a new table instead of modifying the existing
oathauth_users table. This is mainly because adding an auto_increment
column to the existing table would be difficult, but also allows us to
update the table definition to follow MW conventions (namely the column
name prefixes). I've also used the opportunity to normalize the device
types onto a separate table.
The migration stage variable is set to SCHEMA_COMPAT_NEW so that
third-party wikis can use update.php normally and don't have to adjust
anything. This means that it needs to be manually set to _OLD on
wmf-config before merging this patch.
Since we're already working with the database schema, this add a new,
currently unused column for the creation data, so that T242847 will not
require a new schema change.
Bug: T242031
Bug: T242847
Change-Id: I6aa69c089340434737b55201b80398708a70c355
Drop the module name from the oathvalidate API result. As far as I can
tell none of the clients of this internal API (Keystone and Striker) use
the field. This is needed for adding support for a single user having
multiple two-factor keys with different types.
Bug: T242031
Change-Id: I06895c153d7db69a3a6a2e9c34ae432bdc6ca96c
This new service is separated from the previous OATHAuth class to give
the service a more accurate name. Also removed unnecessary injected
services and do some other minor cleanup.
Change-Id: I8d5fbc7594b69168dc0c8bfade1ac172a5aeef6f
This patch has a syntax error. Once fixed, after it's applied to
the original postgres schema (P31006) it makes no difference and
can safely be dropped.
Bug: T312744
Change-Id: Ief18c3a428979d6c7f3592b5763630ac19b85d83
Since core change dffca06 the fieldExists function is only for
maintenance database connections.
Phan reports the type error, the real object on runtime implements the
necessary method, so adjust the doc
Follow-Up: I282cd08d47be1e16cd05903d92561da04889768f
Change-Id: I6d78b3958dc68a61be7e6811b36cc772fa165ffd
This reverts commit 6898d6ba93.
Reason for revert: the transition is apparently not completed yet
Bug: T305029
Change-Id: Ie5079b25bf4403da7bbe9aaa927f40190904bf20
Migration is handled by UpdateTables::switchTOTPToMultipleKeys()
The transition has been completed at WMF as well.
Bug: T304375
Change-Id: I0e6d30075dfbd66d692cd8a5e3f7c9ebf44bc065
The migration from `oathauth_users.secret` to `oathauth_users.module`
was added in I71286534d21d950834. It resides now in the UpdateTables
class, which runs from the LoadExtensionSchemaUpdates hook.
The transition has been completed at WMF as well.
Bug: T304375
Change-Id: I5fa88704c6da2ae2679a19e0c5a2cfe7f3bf5f50
OATHUser::disable sets the 'module' value to null, but
OATHUserRepository::remove reads that value, in order to add the type
to the log entry, resulting in fatals.
Bug: T304350
Change-Id: Ied622f1ba65bfabad3f048dbca885e4dadab0907
This reverts commit 6f37618f4f.
We are later calling isLegacy and that is checking whether
'secret' is set, but due to the change in the select,
'secret' is never set, breaking the functionality of isLegacy().
Change-Id: Ic2c53dca6d1b1608192a5722408f157505187092
...instead of `SELECT *`, in anticipation of future schema changes.
Notably, we didn't need to select the `id` field, since we don't ever
use it (spotted by Thiemo!).
Change-Id: I1089199bdad70401684377d88877eccc689427f9
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
Creating a HTMLForm (or OOUIHTMLForm) without passing in a context is
deprecated now.
Bug: T301866
Change-Id: I35eb85f5089bcef04624e5f72fd1a4389be87de9
Depends-On: Ic65c8934ab33c6d1ca0356011923f8933c5072ca
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
This allows iOS/iPadOS/macOS to suggest filling codes from sms/the built in totp authenticator (in upcoming versions).
Bug: T289086
Change-Id: I555b05fad4806a37a95afcbc63e143efc424f9d3
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
Follows-up c943f75.
* Use foreach to iterate the list of tokens, instead of i-to-length.
* Remove the redundant 'retval = false' assignment, as this was
within an `if (!$retval)` block where the only previous assignment
to it was either retval = 1 or retval = false. Hence redundant.
* Remove the conditional that made the list only checked if the
list was not identical to `[ 0 => "" ]`.
It is unclear to me why this check existed.
I can imagine one of two scenarios, neither of which appears
to be the case:
1. Maybe the scratch list contains 10 tokens plus an empty string,
and if we see it only contains that, we know it's logically empty
and don't "need" to iterate the list.
Except... iterating the list is cheap, so why bother?
2. Maybe the scratch list contains 10 tokens plus an empty string,
and we don't want to allow the empty string to be considered
a valid scratch token to we skip the loop if that's the only
one left.
Except... if that were the case we'd be in trouble as it
isn't being disallowed when the list contains other items
still. And again, afaik it never contains an empty string,
and hopefully empty input is already rejected by now.
Neither of these are good reasons to remove the code without
knowing what it was for though, so I'd rather we figure this
out before merging. I can restore the check if it's non-trivial
to find out.
Bug: T256918
Change-Id: Ide4160bdc18bc47da9632791fb4321e44d6d115a
* Stop returning return values of function that don't return anything
* Remove & from IManageForm reference
Change-Id: I7afa12a4f154cabee03be8947a0bfaadf9598a03
Hook was part of Extension:OpenStackManager, but removed by REL1_35, so unnecessary
I4741fcb073f8463f017bc1b477206dee801b662b / 46d9149c2db7c2b2d4573bede74b54779d66bee8
Change-Id: I2c5f99bfa9028c57a1eadbd81a51f84b47668848
Since T209749, privileged users have an UI to query 2FA status.
We should allow them to do the same thing via the API as well.
Bug: T250901
Change-Id: I28720c762ca595c0ab83aa400f0a593ed6a9285e
It's using wikitext, so it must be given to the parser.
Follow-up to I2abc96bea0543d600c3a48361da1a626d27d5067
Change-Id: Id6d938c2d2d5775d55d3c4c1aeeaa1c002294a9f
Due to using unset(), array keys would be preserved, and therefore, for loop would crash.
Now using array_splice, but had to "reset" the values on construct to fix currently broken
arrays.
Bug: T244308
Change-Id: I6f3dd3df95d5a071b92aa7693ed7ae3fddf35a9d
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
* MediaWiki.Commenting.FunctionComment.MissingReturn
Additional changes:
* Also sorted "composer fix" command to run phpcbf last.
Change-Id: Idb1b91244e653b2ba2e27bceb3eba769577124a9
It's not a query module, so this doesn't actually do anything.
Non query modules are private by default, so ApiMain->setCacheMode()
is not needed
Change-Id: I789edbf0693f8b1928fb32c3aedc0d8899aecc40
Make sure user is asked to re-authenticate (if needed) only on initital request,
not after submitting the form
Bug: T235645
Change-Id: Ic315f49ac5810da0a703ccf4b51f558d17f905fb
- When explictly disabling a method
- When method is implicity disabled if user switches to another method
Bug: T232008
Change-Id: I97a96ca7c1935ecb3a81aea35f607b8ff9f8817d
Make sure that particular form is only loaded when it actually makes sense
for it to load, not when its just requested.
Bug: T218211
Change-Id: Ibae0279451b4a6a4a1d1ce212bbbbf919900a46d
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